lilypond 2.12.3 FTB with Python 3 selected

[gale@…]

The first point is that this port does not have an explicit dependency on any version of python. In fact, it works for any 2.4 <= python < 3. (I tested python27, and from the comments in the python code it appears to support at least back to 2.4.) But the port pulls in specifically python25 indirectly via at least one of its deps, mftrace. So python25 should be added as an explicit dep of lilypond to show that not only do we need python25 installed, we need it selected.

Now to the basic issue of not building when Python 3 is selected.

As has been pointed out before, this is going to be an increasingly common problem, as more and more MacPorts users make the switch to Python 3 while not all upstream sources support it yet for the snippets of Python so many ports contain.

Here is a general solution for when a port depends on a specific version of Python, not just the case of 3 vs. 2: port creates its own symlink to the required python version inside a directory it controls, then pushes that directory onto the front of PATH for the duration of the build. (Perhaps for configure also.)

Alternatively, for any particular port, we can try to create a patch that makes the port's python code compatible with Python 3. Usually, it's just a matter of de-tabifying sloppy indentation, and changing "print >> f" to "f.write". (Thankfully, the Python core devs have not yet removed support in Python 3 for the old "%" string formatting operator, as threatened.)

But in some cases the conversion could turn out to involve real work, so it should really be a job for upstream. In practice we can't wait for that to happen; it could take months or years.

So I recommend the PATH hack.

[nerdling (Jeremy Lavergne)]

If I'm reading this correctly, there are two issues: the program doesn't build against a specific version of python and nothing prevents python3x from satisfying the dependency.

I'd just as soon look for a configure flag or patch something to explicitly use a given version of python indicated through variants. This prevents python3x from working. However, you indicate this is a major problem for all ports in the future. Why not run through all the port tree and do a conflicts python31 for anything with python in it (unless we know it works)? It feels much easier on everyone.

[gale@…]

Replying to snc@…:

If I'm reading this correctly, there are two issues: the program doesn't build against a specific version of python and nothing prevents python3x from satisfying the dependency.

No, not exactly. From the dependency point of view, the port is pulling in a good version of python, python25. python3x does not play any role at all there.

The problem is that even though python25 is correctly pulled in as a dependency by the port file, the build proceeds to ignore it. It runs python31 instead, causing it to fail.

That is because the build scripts don't call up version 2.5 of python explicitly. They just run python. So the version of python that will actually run is totally independent of the port file. It depends instead on whatever the user happened to set as the default version of python using the python_select port. Or possibly even no python at all will run if the user never used python_select.

So I guess another fix would be to go through the build system of this port - makefiles, scripts, and python file shell bangs - and patch them all to run python25 explicitly.

I'm suggesting that maybe the time has come to implement a general solution that will provide an easy fix for all ports that have this problem. Instead of hunting for a port-specific hack each time.

But if the MacPorts team decides against that and just fixes this port, I'll happily install it :)

[nerdling (Jeremy Lavergne)]

Well the problem tends to be the ticket is assigned to the maintainer and that's the last the team sees of it. Have you brought this up with management or filed a ticket filed against base instead of a port?

[ryandesign (Ryan Carsten Schmidt)]

Replying to gale@…:

So I guess another fix would be to go through the build system of this port - makefiles, scripts, and python file shell bangs - and patch them all to run python25 explicitly.

I believe that's what we've done in other ports, so doing so here as well would be consistent with established practices. Adding a lib dependency on python25 to make this port's needs clear isn't a bad idea either.

I'm suggesting that maybe the time has come to implement a general solution that will provide an easy fix for all ports that have this problem. Instead of hunting for a port-specific hack each time.

But if the MacPorts team decides against that and just fixes this port, I'll happily install it :)

I have no objection to a general solution, and your PATH idea sounds like a plausible fix, but python ports are one area of MacPorts I am not experienced with, and I don't have time to work on this problem now either. If you have a general suggestion, ideally accompanied by a working patch for, say, the python portgroups, and can file that in a new ticket, or maybe bring the matter up for discussion on macports-dev first, that might help move this forward.

[nerdling (Jeremy Lavergne)]

I'm planning on putting in variants that do full-path qualifiers for python. While it's frustrating in that it will only work with a single version of python at a time, it addresses the issue. I did this in devel/depot_tools. Sound like what we're after?

[gale@…]

Replying to snc@…:

I'm planning on putting in variants that do full-path qualifiers for python. While it's frustrating in that it will only work with a single version of python at a time, it addresses the issue. I did this in devel/depot_tools. Sound like what we're after?

Sure, that's great. It sounds like a lot of extra work, though, both now and for maintenance in the future. I'm sure you'll be careful to get all the deps straight.

What will be the default variant?

[nerdling (Jeremy Lavergne)]

Presently +python26 is the default, mimicking what is mainstream for the OS. Granted, the MacPorts version of python26 will always be more up-to-date than the one in the OS. Ryan, is this the standard default or is it up to maintainers?

[nerdling (Jeremy Lavergne)]

Added in r75468, using python27 by default.