How to handle different versions of Python
ryandesign at macports.org
Thu Sep 6 13:54:20 PDT 2007
On Sep 6, 2007, at 15:27, Derek Harland wrote:
>>> is there something we can do about these duplicated ports? As we
>>> 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
>>> 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
> (i) a python package will want to install itself into the "usual"
> place, which is
> (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.
More information about the macports-users