py-mercurial

[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. If Python 3 ever becomes preferable they can all switch to it for python.default_version at the same time.
> >
> > $ port list depends_lib:mercurial
> > hg-forest                      @20101118       devel/hg-forest
> > py-mercurial_keyring           @0.5.0          python/py-mercurial_keyring
> > py24-hgsvn                     @0.1.9          python/py-hgsvn
> > py25-hgsvn                     @0.1.9          python/py-hgsvn
> > py26-hggit                     @0.3.1          python/py26-hggit
> > py26-hgsvn                     @0.1.9          python/py-hgsvn
> > py27-hggit                     @0.3.1          python/py27-hggit
> > py27-hgsubversion              @1.4            python/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 choice but to
> make mercurial replaced_by py-mercurial.
>
> I really don't think it's unreasonable for mercurial and its dependents
> to just depend on a single python version though, so long as it's
> reasonably current. Although someone always complains when they have to
> install n+1 ports instead of their current n...

I don't disagree with you on this point per se; it's just that making
this py-mercurial (with subports) 1) takes the work of submitting
updates for `port list depends_lib:mercurial` out of the job of
humans, and 2) allows for testing older python versions easily

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 mercurial mercurial26, etc). The logic looks to be in
place for this to happen in the port group file

ii) what should be done with ${prefix}/share and ${prefix}/etc? Put
them in in ${python.prefix} and change the links? i.e. each python
version of mercurial will conflict with the installed files in
share/man, share/doc, etc/mercurial, etc.

Thoughts about (ii)? If the macports group is willing, this can pretty
much all be handled with a new patch for the python group (basically,
destroot everything into ${python.prefix} and then create symlinks
automatically when using 'port select') but that is potentially a big
change and I don't want to start that kind of work if it's just going
to be rejected.