[22092] trunk/dports/python

[Weissmann Markus]

On 20.02.2007, at 11:44, Jyrki Wahlstedt wrote:

> On 18.2.2007, at 19.39, Markus Weissmann wrote:
>
>> On 18.02.2007, at 17:47, Yves de Champlain wrote:
>>
>>> Le 07-02-17 à 14:15, Blair Zajac a écrit :
>>>
>>>> Yves de Champlain wrote:
>>>>> Le 07-02-17 à 11:32, Yves de Champlain a écrit :
>>>>>>
>>>>>> Le 07-02-17 à 11:18, source_changes at macosforge.org  
>>>>>> <mailto:source_changes at macosforge.org> a écrit :
>>>>>>
>>>>>>> Revision
>>>>>>>     22092 <http://trac.macosforge.org/projects/macports/ 
>>>>>>> changeset/22092>
>>>>>>> Author
>>>>>>>     mww at macports.org <mailto:mww at macports.org>
>>>>>>> Date
>>>>>>>     2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007)
>>>>>>>
>>>>>>>
>>>>>>>       Log Message
>>>>>>>
>>>>>>> new port py25-bz2 - python 2.5 bindings to bzip2
>>>>>>
>>>>>> I am a bit confused.  Python 2.5 is presented as current  
>>>>>> production version on python.org, but these commits make it  
>>>>>> look like a special case.  Is there some sort of problem with  
>>>>>> python 2.5 on Mac ?  Or is this a problem with how python is  
>>>>>> managed in MacPorts ?
>>>>> Just let me be a little more precise : could there be py24-*  
>>>>> and py25-* ports for python ports that use a specific PortGroup  
>>>>> and py-* ports for python packages that don't use a PortGroup ?
>>>>
>>>> But wouldn't that require the Python builds to have a common  
>>>> shared place to look for non-binary modules, so we only have to  
>>>> depend upon one port.  Also, non-binary modules that depends  
>>>> upon binary modules would still need to be versioned for each  
>>>> version of Python, I think :)
>>>
>>> Yes, that is part of the question.
>>>
>>> I maintain a few python ports (gtk2, gobject and cairo) while not  
>>> being really proficient with python setup and configuration.
>>>
>>> But these ports don't belong to a portgroup but rather look for  
>>> python through a configure script and will accept both 2.4 and  
>>> 2.5, so should I still make py25 versions of them ?
>>>
>>
>> Depends: If the port just needs "some" python interpreter at run  
>> time, you don't need a py- named port at all, so are just for  
>> python modules.
>> For python modules the problem is, that they install themselves in  
>> $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or  
>> taken 2.3 into account: three) directories, or at least I wouldn't  
>> try to - there is code that works with 2.4 but not 2.5 and vice  
>> versa, so we'll run into problems here, sooner or later.
>>
>> Currently our "main" python is v2.4 and I'd say we'd stay with  
>> that at least until 2.5.1 is out. But even then there is software  
>> that only will work with 2.4, so please don't move py- (2.4) ports  
>> to py25- (2.5) ones. If you need a python 2.5 version of that  
>> module, duplicate the port. Duplicates are fine here, as I'd  
>> expect that some modules will switch to 2.5 compatible code so we  
>> will probably have something like this in the future:
>> py-module, version 1.8
>> py25-module, version 2.2
>>
>> So we should approach this "switch" slowly, duplicating all the  
>> modules we need for 2.5 - if they work. In some years we probably  
>> can then nuke the py- (2.4) modules when the py41 ports take  
>> over... ;)
>>
>>
>> cheers,
>>
>> -Markus
>>
> Well,
> I beg to differ once again (though I am not sure it makes any  
> difference). The ports with no version number should always be for  
> the latest versions. If ports are duplicated or version-dependent  
> ports are written, they should always be for previous versions that  
> for one reason or other are incompatible. The structure should be  
> simple and consistent (e.g. like in the system frameworks), that  
> benefits us all. But again, I do not make the decisions here  
> (though if all ports are handled like this, what is the result).
>

I'm sure we all want the best solution and that's why we are  
discussing this - my arguments weren't meant to be dictatorial  
decisions from above... ;)

But back on topic: I think you are right in that it is not obvious  
that the prefix "py-" is connected to Python 2.4, while py25- is to  
2.5 (and where the hell are the py24- ports?)
In a perfect world and if we still were in the planning phase, I'd  
totally agree with you on that one. Point is though, that we already  
have some hundred ports prefixed "py-" that use Python 2.4. If we  
silently change even just some of those, users will be surprised and  
probably pissed. We have two ways out of this dilemma: (i) Make a  
major announcement and rename all current "py-" ports to "py24-" or  
(ii) leave the "py-" ones like they are and make it better with the  
"py25-" ports. For the least-surprise for existing users (and  
existing ports that depend on Python modules) I am in favor of the  
second model - and also because this is _way_ less work for us.

Perhaps there is a third possibility I missed or a killer argument  
for (i) - I'm open to good alternatives.


-Markus

---
Markus W. Weissmann
http://www.mweissmann.de/