How to handle different versions of Python

[Derek Harland]

>> 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.