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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
