
On Tue, 2008-04-15 at 13:01 +1200, Greg Ewing wrote:
David Cournapeau wrote:
what is needed is a stable API for the used packages.
That's a nice ideal to aim for, but it's only achievable for old and mature packages.
I don't think so. It requires vigil on the part of the maintainer, but even young packages can have a sane versioning policy.
One could change the package name every time the API changes, but then *any* change to the API would make the package unusable by apps expecting an earlier version, even if the new API is backwards compatible.
Having said that, I just realised you can address that by putting in symlinks for the previous versions.
I don't think that's supported on Windows.
So, I hereby propose the following convention for naming of Python packages:
packagename_<version>
I don't know that this is an actual replacement for setuptools (rather a way to simplify setuptools), but I like the idea in general. However what I'd rather see is: site-packages/package/major_version It would keep the site-packages directory from becoming a giant mess and be more portable.
where <version> is a number or other identifier that is changed whenever the API changes in any way.
I think the convention is major.minor where minor releases are backwards-compatible and major releases aren't expected to be (but might be). Sometimes this is confusing as projects will do a major version release due to say, major code-refactoring that doesn't necessarily affect the API, so the API "version" isn't necessarily reflected in the package version. On the other hand, not using the higher version certainly won't break existing code either, so it's rather moot whether you *could* use the higher versioned software if your concern is not breaking an existing system. Regards, Cliff