python24-26 policy

[Ryan Schmidt]

On Dec 9, 2012, at 09:09, Rainer Müller wrote:

> This is especially a problem as other ports implement a different way to
> select the version for modules/libraries. For python, the default for
> py-foo is always py24-foo.

Actually, the default is py24-foo only if "24" is in python.versions.

Otherwise, assuming "27" is in python.versions, the default is py27-foo.

> For perl, requesting p5-foo installs the
> p5.XY-foo depending on the +perl5.XY variant of the perl5 port. With
> ruby, rb-foo refers to ruby 1.8 and rb19-foo to ruby 1.9, while no
> rb18-foo exists at all.
> 
> I am not saying that the ways perl or ruby handle this are any better,
> but it's confusing that this there is not one unique way to handle all this.

The python-1.0 portgroup is probably one of the best-engineered portgroups that we have. It improves on the earlier pythonXX-1.0 portgroups and introduced the idea of automatic subports. It does a lot of things right. It takes a little time to read through the portgroup and understand how it works, and it does its magic using some lesser-known features of Tcl such as variable traces (in the form of one of the lesser-known MacPorts features, option_proc), but most users won't have to read through it, and the experience of actually using the portgroup in a port is quite good. Defaulting to py24 if "24" is in python.versions was designed to help users upgrade from the old pre-unification py ports, and I think was supposed to be changed to always defaulting to "27" after that transition was done, but unfortunately the transition is still ongoing. But we could easily declare python 2.4 dead today, change the default to py27, and then continue working on removing py24 subports everywhere at a leisurely pace. That would at least fix the users who don't know not to install "py-foo". It would make trouble for users actually still using python 2.4, but my supposition is that there aren't any still doing so deliberately.

The perl5-1.0 portgroup is from the early days of MacPorts so it may not be the best example. In particular its use of a setup procedure seems to be out of fashion these days. The perl5 port used to actually install the perl software. Then later separate perl5.XX ports were created and the perl5 port became a metaport with variants, which caused problems because the p5 modules would then build differently depending on which perl5 variant you had selected. IIRC this is what led to the development of the subport feature, and automatic subports were retrofitted into the perl5-1.0 portgroup. Defaulting to the subport corresponding to the selected perl is weird but seems convenient; I hadn't realized until now that it did this. If it's harmful it could be changed to always default to p5.12. The perl5 metaport dates back to a time before we had the "port select" mechanism, which is what should really be used to select the desired perl. https://trac.macports.org/ticket/29763

The python-1.0 portgroup influenced me while writing the php-1.1 portgroup (which was an extensive rewrite of php5extension-1.0) and I'm very happy with how that portgroup turned out. I think in some ways it's even better than python-1.0, plus it's better commented. The ports using php-1.1 read cleanly and work great.

The ruby-1.0 portgroup unfortunately I've never understood. It's confusing to read, there are too many options to the setup procedure, and it's not documented well. I tried to make a port with it once and couldn't understand how. The portgroup was made before we had subports and has not had automatic subports retrofitted into it. The ruby and ruby19 ports were made before we had "port select" and have not been updated to support that either. The ruby situation in MacPorts needs some serious love to bring it up to the level of other languages.