[22092] trunk/dports/python

[Yves de Champlain]

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 ?

yves