Le mercredi 01 octobre 2008 à 11:00 -0700, Toshio Kuratomi a écrit :
- The heuristic encourages bad practices. Versions need to be parsed
by computer programs (package managers, scripts that maintain repositories, etc). Not all of those are written in python. Having things other than letters and dots in version strings is problematic for these programs. For instance, here's something that setuptools versioning heuristics allow you to do:
foo-1.0rc1 foo-1.0 foo-1.0post1
But here's how rpm would order it: foo-1.0 foo-1.0post1 foo-1.0rc1
In Fedora we have rules for puting non-numeric things in our release tag to work around this:
version: 1.0 , release: 0.1.rc1 version: 1.0 , release: 1 version: 1.0 , release: 2.post1
This is not all inclusive, but you can see, we have to move the alpha portion of the version to the release to ensure that the upgrade path will move forward sensibly.
In Debian, we have the ~ character to handle such versions easily: foo_1.0~rc1 << foo_1.0 << foo_1.0post1
In all cases, this is not something that matters much to us since the version of the tarball in Debian does not need to be the same as that of the upstream one; for example, 1.0rc1 will always be renamed to 1.0~rc1.
- This is more important but much harder. Something that would really
help everyone is having a way of versioning API/ABI. Right now you can specify that you depend on Foo >= 1.0 Foo <= 2.0. But the version numbers don't have meaning until the actual packages are released. If Foo-1.0 and Foo-1.1 don't have compatible API, your numbers are wrong. If Foo-1.0 is succeeded by Foo-2.0 with the same API your numbers are too restrictive. If you lock the versions to only what you've tested: Foo = 1.0 then you're going to have people and distributions that want to use the new version but can't. Some places have good versioning rules:: https://svn.enthought.com/enthought/wiki/EnthoughtVersionNumbers
Other places say they have marketing departments that prevent that One possibility would be to have MyLib1-1.0, MyLib2-1.0, MyLib2-2.0, etc with the version for marketing included in the package name.
Another idea would be to have API information stored in metadata but not in the package name. That way marketing can have a big party for MyLib-2.0 but the API metadata has API_Revision: 32.
Fully agreed. We need to be able to specify an API version one way or the other. The simple way is to set naming rules that postfix the marketing name with such an API version, but I don’t think developers are going to follow that, so it needs a more formalized way to be specified.
I have no love for how pkg_resources implements this (including the API) but the idea of retrieving data files, locales, config files, etc from an API is good. For packages to be coded that conform to the File Hierachy Standard on Linux, the API (and metadata) needs to be more flexible. We need to be able to mark locale, config, and data files in the metadata. The build/install tool needs to be able to install those into the filesystem in the proper places for a Linux distro, an egg, etc. and then we need to be able to call an API to retrieve the specific class of resources or a directory associated with them.
Amen to that. Currently, we find all kind of data and configuration files right into the python package directories, and this must really stop. The python-specific package management tools wouldn’t need to be so complex if you only found python modules in the python modules directory.