py-mercurial

Rainer Müller raimue at macports.org
Thu May 10 05:40:09 PDT 2012


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

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.

> 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.

In my opinion py-* ports should be limited to python modules. Software
such as mercurial should be provided with a sane name. I don't see why
we need to offer choices for different python versions here. The best
choice for all python-dependent software is python27 at the moment.

A downside of (ii) is that no version would be selected by default and
thus, user action is required to make the software work.

Rainer


More information about the macports-dev mailing list