py-mercurial

[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-destroot phase. Something like this:

1) loop through ${python.prefix}/{bin,etc,share,lib,libexec}
2) output into 'select' files: base, none, etc.

Now everything would be prefixed into the correct python version and 'man
hgrc' would also work.

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

Hmm, what about packages that are both? Ports like boost come to mind. The
portfile for boost solved t his issue by using variants ... but as we all
know, dependencies can't easily use variants. The subport solution uses
code generation and forces everything dependent to do the same. So, it
would seem that this problem is equivalent to the problem of dependencies
on variants.

I don't see an easy and general solution but for mercurial this could be
solved with making the links and 'port select' work. I'm about a +0 on this
approach, though.

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

Well, couldn't something be done in the post-activate stage? "if nothing
selected, then select this one"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120510/b72e4f53/attachment-0001.html>