mercurial: use python27

[singingwolfboy@…]

We should default to the latest stable 2.x python, in this case Python 2.7. Patch attached.

[joshmoz@…]

Please don't do this until bug #27916 has been addressed. It'll cause a problematic version of python to be installed on more systems.

[deric@…]

#27916 is ​http://bugs.python.org/issue9516 upstream

[marc.schlaich@…]

Why not creating py26-mercurial and py27-mercurial according to the convention of python packages?

[ryandesign (Ryan Carsten Schmidt)]

Because mercurial s not a python module; it is a program that happens to use python.

[marc.schlaich@…]

It is listed in PyPI (​http://pypi.python.org/pypi/Mercurial), so it is obviously a python package!

To force a specific version of python is not very recommended. In combination with the port "tortoisehg" it forces a huge dependency list if the python version of mercurial is not your default python version (see #29498).

[marc.schlaich@…]

Cc Me!

[sean@…]

Cc Me!

[felix.buenemann@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #29821, #30255.

[marc.schlaich@…]

I should note again: Why there is no py26-mercurial and py27-mercurial? There are a lot of follow up packages which requires Mercurial as a package, for example hggit and hgsubversion, which exists only for Python 2.6 because of this weak port name.

[mf2k (Frank Schima)]

Cc Me!

[macports@…]

Replying to marc.schlaich@…:

I should note again: Why there is no py26-mercurial and py27-mercurial? There are a lot of follow up packages which requires Mercurial as a package, for example hggit and hgsubversion, which exists only for Python 2.6 because of this weak port name.

As stated before, that naming convention is for python modules, not applications using python. It makes sense to have modules installed for more than one python version, but it does not make sense to have more than one instance of a Python-using app installed.

The more correct solution would be to use variants and have the default variant be python27 but use python26 or whatever other variant if that is the installed version. How to make that happen is something I haven't the time to dive into, but there are some ports that work this way (e.g. avahi).

[singingwolfboy@…]

Actually, it might be more correct to separate the mercurial port into two parts: the Python module installed in the site-packages directory, which would follow the module naming convention of py2{5,6,7}-mercurial; and the CLI client (/opt/local/bin/hg) and all the support files under /opt/local/share/mercurial, which would simply be called mercurial. I.E. separate the parts of mercurial that are dependent on Python version from the parts of mercurial that aren't. We might also need to use the port_select behavior in Macports to switch between what Python version you want for the mercurial CLI client.

This seems like the most robust solution, but also the most work. :(

[pixilla (Bradley Giesbrecht)]

Replying to joshmoz@…:

Please don't do this until bug #27916 has been addressed. It'll cause a problematic version of python to be installed on more systems.

Replying to deric@…:

#27916 is ​http://bugs.python.org/issue9516 upstream

​issue9516 has status: closed, resolution: fixed.

[pixilla (Bradley Giesbrecht)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #31417.

So, can this be done now?

[mamoll (Mark Moll)]

Cc Me!

[jmroot (Joshua Root)]

r86604

[anddam (Andrea D'Amore)]

Replying to jmr@…:

r86604

Does this need variants in order to handle other python's versions as the port name is not in py-* form?