Unified Python portgroup

[Ryan Schmidt]

On Jan 10, 2013, at 16:51, Freek Dijkstra wrote:

> On 10-01-2013 15:25, Jeremy Lavergne wrote:
> 
>> You need:
>> sudo port -d install subport=py27-pdfrw
> 
> Thanks Jeremy,
> 
> Your answer is spot-on. With this syntax, the modified Portgroup behaved
> as it should.
> 
> I never made the mental link between "Unified portgroup" and "subport"
> otherwise I would have probably found it on the mailing list (The guide
> does not yet mention either of them).

Yes, we use the term "unified" to describe a portgroup that lets you create a single port that automatically creates multiple subports, one for each supported version of the related language. We have unified portgroups for python (python 1.0), perl (perl5 1.0) and php (php 1.1).

You're right, documentation is lacking. Here is the request to document the subport feature:

https://trac.macports.org/ticket/36957

Here is the request to document the php portgroup:

https://trac.macports.org/ticket/25170

Note that in the case of the php portgroup at least, pretty good documentation is provided in the form of comments in the portgroup itself. When in doubt, read the portgroup.


> A suggestion: Apparently, the Portgroup was clever enough to figure out
> I have Python 2.7 installed. Would it be possible to improve the error
> message to say:
>>> Error: No subport specified. Did you mean 'port install
> subport=py27-pdfrw'.
> instead of the current:
>>> Error: Dependency 'py27-pdfrw' not found.

The portgroup merely causes the stub port to declare a dependency. Once MacPorts tries to evaluate that dependency, it has no idea that it's meant to be a subport of the current port. It just knows that the dependency is not in the index yet, so it prints the error.

The situation isn't much different from the one where you're developing two new ports X and Y, and one of them X depends on the other one Y. If you have not already installed Y, and you have not run `portindex`, then trying to install X will tell you that dependency 'Y' was not found (in the index).

It might be possible in the python 1.0 portgroup to check whether the subport is in the index, and if not, don't declare a dependency but instead print your suggested error in a pre-fetch block or something. A similar block should be added to all unified portgroups in that case. It could be worth considering.


> On 10-01-2013 19:21, Ryan Schmidt wrote:
> 
>> Yes—provided you've already added the line "python.versions 27"
>> (and possibly any other python versions you want to support, e.g.
>> "python.versions 25 26 27").
> 
> I did, exactly that: "python.versions 25 26 27". To my surprise the
> following command was accepted:
> 
>> [root at lampje] Code/macports/py-pdfrw# port install subport=py32-pdfrw
>> --->  Computing dependencies for py32-pdfrw
>> --->  Fetching archive for py32-pdfrw
>> --->  Attempting to fetch py32-pdfrw-0.1_1.darwin_11.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/py32-pdfrw
>> --->  Attempting to fetch py32-pdfrw-0.1_1.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/py32-pdfrw
>> --->  Attempting to fetch py32-pdfrw-0.1_1.darwin_11.x86_64.tbz2 from http://packages.macports.org/py32-pdfrw
>> --->  Attempting to fetch py32-pdfrw-0.1_1.darwin_11.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/py32-pdfrw
>> --->  Fetching distfiles for py32-pdfrw
>> --->  Verifying checksum(s) for py32-pdfrw
>> --->  Extracting py32-pdfrw
>> --->  Configuring py32-pdfrw
>> --->  Building py32-pdfrw
>> --->  Staging py32-pdfrw into destroot
>> --->  Installing py32-pdfrw @0.1_1
>> --->  Activating py32-pdfrw @0.1_1
>> --->  Cleaning py32-pdfrw
> 
> Is this intended?

With the python 1.0 portgroup this happens to work, yes. With the php 1.1 portgroup you can try it but the build will fail.

I consider it a bug that this is possible, and filed this ticket awhile ago:

https://trac.macports.org/ticket/34619

As I show there, you can do some very wrong things with this (mis)feature.


> I suspect so, otherwise package owners still has to
> update the package everytime a new Python versions is released.

That's actually exactly right: port owners do need to update their ports every time a new compatible version of Python is released. MacPorts cannot know what Python versions each port is compatible with; each port author must test his port for compatibility with each Python version and use the python.versions line to indicate the results.


> However,
> in that case, I do not fully grasp what the purpose is of the line
> "python.versions 25 26 27" -- it is neither used to pick the default
> installer (I have to explicitly specify the subport), nor is it used to
> enforce that installation only occurs for supported Python versions.

Setting "python.versions" is what tells the python 1.0 portgroup to run the "subport" command (once for each version) to set up the subports. This is what causes the subports to go into the index when `portindex` is run. You'll also see these ports listed as subports when you run e.g. "port info py-pdfrw". For the stub port (the py-pdfrw port itself, which installs no meaningful files of its own), the python 1.0 portgroup adds a dependency on the default subport. The default subport is the largest 2x version you support, which is usually 27 since that is the newest version of python 2 and there will never be any newer versions of python 2, all future development having moved to python 3. The exception is if "24" is in python.versions, in which case that is the default subport. The purpose of this exception is to handle upgrades from old pre-unified python 2.4 ports, which were not named py24-foo but instead just py-foo. When adding a new unified python port for which no pre-unified python 2.4 port existed, you should override python.default_version and set it to the largest 2x version you support, e.g. 27. Or better yet, don't add a 24 subport at all; I'd really like to get all of python 2.4 phased out of MacPorts as soon as is convenient.