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