> > 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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
