[Distutils] [pyconuk] "just use debian"

[Josselin Mouette]

Le mardi 30 septembre 2008 à 17:20 +0200, Tarek Ziadé a écrit :
> > Again, when a C library changes its ABI, we do not allow it to keep the
> > same name. It's as simple as that.
> 
> I see, so there's no deprecation processes for a package  ?

Not per se. It is the job of the package manager to propose removing
deprecated packages when they are no longer available in the repository.

> I mean, if you change a public API of your package , you *have* to
> change its name ?

Yes, this is the requirement for C libraries, and we try to enforce it
as well for other languages.

> My convention is to :
>  - keep the the old API and the new API in the new version, let's say "2.0"
>  - mark the old API as deprecated (we have this "warning'" module in
> Python to do so)
>  - remove the old API in the next release, like "2.1"
> 
> But I don't want to change the package name.
> 
> And the development cycles in a python package are really short
> compared to OS systems, in fact
> we can have quite a few releases before a package is really stable.

I don’t think the requirements are different from those of C library
developers. There are, of course, special cases for libraries that are
in development; generally we take a snapshot, give it a specific soname
and enforce the ABI compatibility in the Debian package. The other
possibility is to distribute the library only in a private directory.
Nothing in this process is specific to C; the technical details are
different for python modules, but we should be able to handle it in a
similar way.

> > This is not an improvement, it is a nightmare for the sysadmin. You
> > cannot install things as simple (and as critical) as security updates if
> > you allow several versions to be installed together.
>
> mmm... unless the version is "part of the name" in a way....

Yes, this is what C libraries do with the SONAME, for which the
convention is to postfix it with a number, which changes when the ABI is
changed in an incompatible way. I don’t know whether it would be
possible to do similar things with python modules, but it is certainly
something to look at.

> > Two conflicting versions must not use the same module namespace.
> 
> I have an idea: what about having a "known good set" (KGS) like what
> Zope has built on its
> side.
> 
> a Known Good Set is a set of python package versions, that are known to provide
> the good execution context for a given version of Python.
> 
> Maybe the Python community could maintain a known good set of python
> packages at PyPI, with a real work on its integrity, like any
> OS-vendor does I believe.

Having a body that enforces API stability for a number of packages would
probably prevent such issues from happening in those packages. However,
that means relying too much and this body, and experience proves it will
quickly lag behind. Furthermore, the need to add packages that are not
in the KGS to distributions will arise sooner or later.

> And maybe this KGS could be used by Debian as the reference of package versions.

We will always need, for some cases, more recent packages or packages
that are not in the KGS.

> -> if a package is listed in this KGS, it defines the version, for a
> given version of Python

You don’t have to define it so strictly. There is no reason why a new
version couldn’t be accepted in the KGS for an existing python version,
if it has been checked that it will not break existing applications
using this module.

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/20080930/cce6113b/attachment.pgp>