Python framework location and Python 3.0 conflict with 2.4
Hi, This is to follow up on this commit: http://trac.macports.org/projects/macports/changeset/34702 We've discussed this briefly before on the list, but I'm of the mind that all new Python frameworks must be installed in a separate directory from the Python 2.4 framework for several reasons: 1) There's a conflict on the ${prefix}/Library/Frameworks/Python.framework/Versions file. 2) I have a requirement that we have multiple framework Pythons installed at the same time. With a deployment to a hundred Mac's or so running PyQt apps running on 2.4, I need to maintain that environment. It would be nice to have Python 3.0 with a framework build installed along side 2.4 so we can port our applications to Python 3.0 (which is source incompatible with 2.x). So I don't care really where the Python 3.0 framework gets installed, but its base must not be ${prefix}/Library/Frameworks. A directory such as ${prefix}/Library/Frameworks/${name} would work for me. Regards, Blair
Blair Zajac wrote:
We've discussed this briefly before on the list, but I'm of the mind that all new Python frameworks must be installed in a separate directory from the Python 2.4 framework for several reasons:
1) There's a conflict on the ${prefix}/Library/Frameworks/Python.framework/Versions file.
Also on Python.framework/{Headers,Python,Resources}. See below.
2) I have a requirement that we have multiple framework Pythons installed at the same time. With a deployment to a hundred Mac's or so running PyQt apps running on 2.4, I need to maintain that environment.
It would be nice to have Python 3.0 with a framework build installed along side 2.4 so we can port our applications to Python 3.0 (which is source incompatible with 2.x).
So I don't care really where the Python 3.0 framework gets installed, but its base must not be ${prefix}/Library/Frameworks. A directory such as ${prefix}/Library/Frameworks/${name} would work for me.
I discussed this with reiffert today on IRC. If everything would work as it should, we would have Python.framework/Versions/{2.4,2.5,3.0} and python_select would link Python.framework/Versions/Current to the according version. And now comes the big "but...": All three ports try to add Headers,Python,Resources symlinks to Versions/Current/{Headers,Python,Resources}. So if another port gets activated it fails on these files. They have to exist, but can't be owned by a port. Sure, we could symlink like Headers -> Versions/3.0/Headers with python_select. But that makes python_select a dependency to get a working framework install. Another solution would be Python24.framework, Python25.framework, Python30.framework. But as frameworks are meant to be installed with different versions (by this Current symlink) we should find some solution to make use of it. Rainer
Rainer Müller wrote:
Blair Zajac wrote:
We've discussed this briefly before on the list, but I'm of the mind that all new Python frameworks must be installed in a separate directory from the Python 2.4 framework for several reasons:
1) There's a conflict on the ${prefix}/Library/Frameworks/Python.framework/Versions file.
Also on Python.framework/{Headers,Python,Resources}. See below.
2) I have a requirement that we have multiple framework Pythons installed at the same time. With a deployment to a hundred Mac's or so running PyQt apps running on 2.4, I need to maintain that environment.
It would be nice to have Python 3.0 with a framework build installed along side 2.4 so we can port our applications to Python 3.0 (which is source incompatible with 2.x).
So I don't care really where the Python 3.0 framework gets installed, but its base must not be ${prefix}/Library/Frameworks. A directory such as ${prefix}/Library/Frameworks/${name} would work for me.
I discussed this with reiffert today on IRC.
If everything would work as it should, we would have Python.framework/Versions/{2.4,2.5,3.0} and python_select would link Python.framework/Versions/Current to the according version.
And now comes the big "but...": All three ports try to add Headers,Python,Resources symlinks to Versions/Current/{Headers,Python,Resources}. So if another port gets activated it fails on these files. They have to exist, but can't be owned by a port.
Sure, we could symlink like Headers -> Versions/3.0/Headers with python_select. But that makes python_select a dependency to get a working framework install.
Another solution would be Python24.framework, Python25.framework, Python30.framework. But as frameworks are meant to be installed with different versions (by this Current symlink) we should find some solution to make use of it.
If we can get the build scripts to automatically run python_select python24 when it's going to build a Python 2.4 Port and then run python_select python25 for Python 2.5 ports, then that would work. But it seems that python_select is for runtime use of MacPorts installed binaries, not build time. Maybe we add a different set of flags to python_select for build time. Blair
participants (2)
-
Blair Zajac
-
Rainer Müller