How to handle different versions of Python

[Ryan Schmidt]

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.