Re: Default choices for port select (was: Re: py-mercurial)

2012-05-29 Thread Sean Farley
>> Sure it is. You could just generate the files needed during the >> post-destroot phase. Something like this: >> >> 1) loop through ${python.prefix}/{bin,etc,share,lib,libexec} >> 2) output into 'select' files: base, none, etc. > > And which port is supposed to install these files? > > Multiple p

Default choices for port select (was: Re: py-mercurial)

2012-05-11 Thread Rainer Müller
On 05/10/12 19:53, Sean Farley wrote: > This is not possible as port select always needs a base file which > cannot be shipped with any of the selectable port options. This is why > we have the *_select ports; their only purpose is to install this > base file. > > > Sure it is. Yo

Re: py-mercurial

2012-05-10 Thread Sean Farley
> > This is not possible as port select always needs a base file which > cannot be shipped with any of the selectable port options. This is why > we have the *_select ports; their only purpose is to install this base > file. > Sure it is. You could just generate the files needed during the post-de

Re: py-mercurial

2012-05-10 Thread Rainer Müller
On 05/10/12 01:47, Sean Farley wrote: > I like the new feature that (2) brings but before I submit my patch, > there a few notes and issues: > > i) it should be possible for the python-1.0 group to create a "port > select" on the fly (port select --set mercurial mercurial27, port > select --set me

Re: py-mercurial

2012-05-09 Thread Sean Farley
tortoisehg                     @2.1.2          devel/tortoisehg > > Oh, right. Well if that needs to work I guess there's no choice but to > make mercurial replaced_by py-mercurial. > > I really don't think it's unreasonable for mercurial and its dependents > to just

Re: py-mercurial

2012-05-07 Thread Rainer Müller
On 05/06/12 22:33, Daniel Ericsson wrote: > hg-forest isn't even compatible with mercurial 2.x, without a > maintainer or a replacing port can we just remove it? or do we need a > grace period as the guide says? If the port is broken already for the last 6 months after mercurial was upgraded to 2.

Re: py-mercurial

2012-05-06 Thread Jeremy Lavergne
> Although someone always complains when they have to > install n+1 ports instead of their current n... Maybe not with pre-built binaries ;-) smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosf

Re: py-mercurial

2012-05-06 Thread Joshua Root
python/py27-hggit > py27-hgsubversion @1.4python/py27-hgsubversion > py27-hgsvn @0.1.9 python/py-hgsvn > tortoisehg @2.1.2 devel/tortoisehg Oh, right. Well if that needs to work I guess there's no

Re: py-mercurial

2012-05-06 Thread Daniel Ericsson
On 6 maj 2012, at 21:14, Sean Farley wrote: >> I didn't go into the fact that there are some ports depending on mercurial >> and I wanted to give those a target to depend on that included the python >> version. But with 24, 25 being on the way out and most ports defaulting to >> 27 it probably

Re: py-mercurial

2012-05-06 Thread Sean Farley
> I didn't go into the fact that there are some ports depending on mercurial > and I wanted to give those a target to depend on that included the python > version. But with 24, 25 being on the way out and most ports defaulting to 27 > it probably will be an issue that goes away. I have about ha

Re: py-mercurial

2012-05-06 Thread Daniel Ericsson
On 6 maj 2012, at 15:01, Joshua Root wrote: > On 2012-5-6 22:30 , Daniel Ericsson wrote: >> Hi, >> >> I want to move mercurial to allow for installation with any version of >> Python, that's supported and the user have chosen as their selected version. > > Just take the current portfile and add

Re: py-mercurial

2012-05-06 Thread Joshua Root
t's gonna be > another cycle of mixed Python installations. > > Mercurial is mostly just a python package, with all the help one gets from > the python portgroup to add different subports for different versions my > first thought is actually to deprecate mercurial and rename the po

py-mercurial

2012-05-06 Thread Daniel Ericsson
ackage, with all the help one gets from the python portgroup to add different subports for different versions my first thought is actually to deprecate mercurial and rename the port to py-mercurial. Is there any reason we should keep the old port around beyond a replaced_by keyword? Some pe