[Distutils] "Python Package Management Sucks"

[Josselin Mouette]

Le mercredi 01 octobre 2008 à 11:00 -0700, Toshio Kuratomi a écrit :
> 1) 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.

> 2) 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.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081001/b6d124d5/attachment.pgp>