[Distutils] [pyconuk] "just use debian"

[Josselin Mouette]

Le mardi 30 septembre 2008 à 14:05 +0200, Tarek Ziadé a écrit :
> On Tue, Sep 30, 2008 at 10:42 AM, Nicolas Chauvat
> <nicolas.chauvat at logilab.fr> wrote:
> > For example, if you require a minimal version of 1.4, you can
> > translate this to a package version of 1.4; it is a bit hackish but
> > will work if you handle epochs correctly. But if the package you
> > depend on has a Provides: blah (1.4), you have no way to map that to a
> > dependency, because you can't know what other versions of the package
> > will provide.
> 
> I am not sure to fully understand, could you provide a real-word example ?

Let’s say you have module bar, contained in the package python-bar. The
last version is 1.4. After that version, it is decided to distribute it
in the same tarball as module bar. It is therefore moved to the package
python-foo, which is at version 1.2. In this case, you can specify in
the metadata :
	Provides: foo
	Provides: bar (1.4)
This is the typical use case for versioned provides.

Let’s say application baz requires module bar with minimal version 1.3,
it will have as dependency:
	Requires: bar >= 1.3
This way it will be happy to find the versioned provides if module foo
is installed, and everyone is happy. Well, except that, if you try to
build a package of baz, there is no way to express correctly that you
depend on python-bar (>= 1.3) or python-foo (>= 1.2).

This is why I’d prefer to have versioned provides simply not part of the
specification. 

Another thing that can cause issues is exact dependencies. If you
require strictly version 1.1 of foo, there is no good way of translating
it into a package dependency. All the following will have serious
drawbacks when facing the real world:
	python-foo (>= 1.1), python-foo (<< 1.1.~)
	python-foo (>= 1.1), python-foo (<< 1.2)
	python-foo (= 1.1-1)

If you allow to specify requires and provides in a sophisticated way,
people will use it and we will run into unmanageable situations when
converting them to packages. If a module provides an API at version 1.2,
it will have to still provide it at version 1.3, otherwise the module
should remain private and never be installed in a public python module
directory. Just like we rename C libraries when their ABI changes, we
need to reach a situation where we can make the same assumptions about
python modules.

> > In all cases, it will be necessary to manually add shlibs-like
> > information to the packages; they could be partly autogenerated like
> > symbol files, but you need a mapping between provided modules and the
> > first version of the package that provides it.
> 
> Is this related ? http://lists.debian.org/debian-dpkg/2006/01/msg00118.html

Yes. The thread you point to did not let to something being actually
implemented, because at that moment, we lacked the necessary metadata.
Since then, setuptools appeared, but it does not provide it in a sane
way and it is not universal. Which is why I’m interested into the
metadata format that’s discussed here.

From this metadata, we will be able to generate some files that express
what is provided and the required version. Something like:
	foo	1.0-1
	bar	1.2~beta3

This way, if another package requires foo (> 1.1) and bar (without a
version requirement), we can convert this dependency into:
	python-foo (>= 1.1), python-foo (>= 1.2~beta3)
which can then be factorized, of course.

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/22307268/attachment-0001.pgp>