[22092] trunk/dports/python

[Blair Zajac]

Yves de Champlain wrote:
> 
> Le 07-02-22 à 11:05, Blair Zajac a écrit :
> 
>> Jyrki Wahlstedt wrote:
>>> On 18.2.2007, at 19.39, Markus Weissmann wrote:
>>>
> 
> skip ...
> 
>>> 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 disagree that the non-versioned py or pm modules should be the 
>> latest version.  While this is nice, in practice, it requires a 
>> forklift upgrade of all the Python modules and I don't see it working 
>> that well unless one or two people want to take on upgrading all the 
>> modules.
>>
>> Then, it would also be nice to have the same modules on the old 
>> version of Python for people who don't want to move to the latest 
>> version of Python for whatever reason, say they have their own private 
>> Portfiles for local modules.  So I would rather see all modules with a 
>> version name in them.
>>
>> BTW, where I'm coming from is using MacPorts in for commercial 
>> products or in a corporate environment deployed to 100's of Mac 
>> desktops where you need to support multiple versions of Python 
>> simultaneously.  I'm not looking at MacPorts just for my own personal 
>> use on a laptop, where these issues are not as important.
> 
> I guess then the best solution is to have, ultimately, no py- ports at 
> all, because they only cause confusion, but rather  only py25 py26 py30 
> etc.
> 
> Then there will be only one question left ... which python port gets to 
> have the great python symlink in bin ?

We could supply two Portfiles that provide this and the MacPorts 
administrator can decide which one to make the default.

Regards,
Blair