Re: How to handle different versions of Python
is there something we can do about these duplicated ports? As we have now a python-3.0 devel port there could be much more ports just for this version.
Wouldn't be a bin:python:python24/25/30 better? The python ports (python24, python25, python30) could create a symbolic link named "python" so it should be there and can be checked.
And for ports which need a specific version we could just check for that one (bin:python25:python25).
I don't use python. But I believe the idea was that there are significant differences between python 2.4 and 2.5, and that there is some software that works with 2.4 but not 2.5, some that works with 2.5 but not 2.4, and some that works with both 2.4 and 2.5 but with significant changes in how that's done. So the decision was to have separate portfiles. I have no information on how python 3.0 fits into the picture now. Perhaps someone who uses python can comment.
The issues are really around how one might support *multiple* installations of python on a box. For example, I run python2.4 in production, 2.5 in development and am fiddling around with the SVN Head of python3. Thus I might need to install a package for each of these pythons because: (i) a python package will want to install itself into the "usual" place, which is /opt/local/lib/python2.x/site-packages (ii) if it contains c-code, it will want to compile itself against a specific python version as the ABI may change. (iii) in very rare cases, you might want to be downloading/compiling a different source file as the author may have released different versions for 2.4 and 2.5 to take advantage of new features in 2.5 Its not really sufficient to just check that *python* exists and install it using that version. Doing so would mean (i) only that version of python would find it on its default import path (given above) (ii) other versions installed by macports would not see it. If you hacked their import path, you would be importing c-modules compiled against a different library version and warnings would be issued This is further complicated by the fact that python3.x is *not* language compatible with the 2.x branch. It will require library writers to review their code and definitely issue a separate release for it (and of course, expect a lot of small little utilised libraries never to be converted) Within the macports framework, it would appear that you either need a separate portfile per python version, or a single portfile with variants +pythonx.x derek.
On Sep 6, 2007, at 15:27, Derek Harland wrote:
is there something we can do about these duplicated ports? As we have now a python-3.0 devel port there could be much more ports just for this version.
Wouldn't be a bin:python:python24/25/30 better? The python ports (python24, python25, python30) could create a symbolic link named "python" so it should be there and can be checked.
And for ports which need a specific version we could just check for that one (bin:python25:python25).
I don't use python. But I believe the idea was that there are significant differences between python 2.4 and 2.5, and that there is some software that works with 2.4 but not 2.5, some that works with 2.5 but not 2.4, and some that works with both 2.4 and 2.5 but with significant changes in how that's done. So the decision was to have separate portfiles. I have no information on how python 3.0 fits into the picture now. Perhaps someone who uses python can comment.
The issues are really around how one might support *multiple* installations of python on a box. For example, I run python2.4 in production, 2.5 in development and am fiddling around with the SVN Head of python3.
Thus I might need to install a package for each of these pythons because: (i) a python package will want to install itself into the "usual" place, which is /opt/local/lib/python2.x/site-packages (ii) if it contains c-code, it will want to compile itself against a specific python version as the ABI may change. (iii) in very rare cases, you might want to be downloading/ compiling a different source file as the author may have released different versions for 2.4 and 2.5 to take advantage of new features in 2.5
Its not really sufficient to just check that *python* exists and install it using that version. Doing so would mean (i) only that version of python would find it on its default import path (given above) (ii) other versions installed by macports would not see it. If you hacked their import path, you would be importing c-modules compiled against a different library version and warnings would be issued
This is further complicated by the fact that python3.x is *not* language compatible with the 2.x branch. It will require library writers to review their code and definitely issue a separate release for it (and of course, expect a lot of small little utilised libraries never to be converted)
Within the macports framework, it would appear that you either need a separate portfile per python version, or a single portfile with variants +pythonx.x
Well if the goal is simultaneous installation of multiple versions of python, then a single portfile with variants is not an option, since you cannot simultaneously install multiple variant versions of a single port. Only one version of a port can be active at once. So you need separate ports, as we have now.
On 7/09/2007, at 8:54 AM, Ryan Schmidt wrote:
Well if the goal is simultaneous installation of multiple versions of python, then a single portfile with variants is not an option, since you cannot simultaneously install multiple variant versions of a single port. Only one version of a port can be active at once. So you need separate ports, as we have now.
I agree. However would it not be possible to (theoretically) have a variant install extra files, so that something like port install some-python-package +python2.5 +python2.4 would install files for both python2.4 and 2.5? I'm not suggesting this as solution ... I don't think its very nice, its more a question for my own understanding of macports. derek
On Sep 6, 2007, at 17:20, Derek Harland wrote:
On 7/09/2007, at 8:54 AM, Ryan Schmidt wrote:
Well if the goal is simultaneous installation of multiple versions of python, then a single portfile with variants is not an option, since you cannot simultaneously install multiple variant versions of a single port. Only one version of a port can be active at once. So you need separate ports, as we have now.
I agree. However would it not be possible to (theoretically) have a variant install extra files, so that something like
port install some-python-package +python2.5 +python2.4
would install files for both python2.4 and 2.5?
I'm not suggesting this as solution ... I don't think its very nice, its more a question for my own understanding of macports.
Oh. Um... well, yes, but... Most ports need to go through phases, generally configure, make and make install. Looks like ports in the python groups get to skip the configure phase, but still need a make (python setup.py build) and make install (python setup.py) phase. MacPorts is designed to do these phases once each per port, but if you wanted to build both python 2.4 and python 2.5 versions of a port, it would probably need to go through each phase twice, once for each version of python. Going through a phase more than once is not so much supported by MacPorts at this point (though some ports come to mind that try very hard to fake it; see "openssl +universal" which is quite messy and "php5 +fastcgi +apache[2]" which is less messy but still not great).
participants (2)
-
Derek Harland
-
Ryan Schmidt