[Distutils] "just use debian"
joss at debian.org
Fri Oct 3 17:32:28 CEST 2008
Le vendredi 03 octobre 2008 à 16:06 +0100, Chris Withers a écrit :
> Josselin Mouette wrote:
> > This information is not accessible directly at import time.
> Two questions as answers:
> - why does it need to be?
It does not strictly need to be, it’s just more convenient ; especially
since you generally have to be compatible with several APIs and have
compatibility code for each of them. Note that the reduced complexity of
removing the old API is by far compensated by the added complexity of
such compatibility code.
> - why not?
Currently there is simply no way to express the API version of a module.
> > If you want
> > to rely on it to check the API compatibility, you’ll end up doing the
> > horrible things pygtk and gst-python did. And believe me, that will not
> > be helpful.
> It's unfortunately not a black'n'white thing...
> ...but if you require a particular API, just define the appropriate
> dependency in setup.py. What's the problem with that?
There are at least two problems with that:
* you cannot reliably translate this to package dependencies (even
when doing it by hand as we do currently);
* it is not possible to install two different APIs for the same
module name on the same system.
> > Indeed, but if we change the package name without changing the file
> > name, we have to make both packages conflict with each other.
Because otherwise the package manager will choke when trying to install
both of them together.
> > This works
> > for distribution packages,
> What do you mean by "distribution package"?
I mean a .deb or a .rpm.
> > but it doesn’t help for third-party addons,
> Why not?
Because you can say in the package metadata: "Conflicts: python-foo",
but you cannot express "this package will break local installations of
module foo". The user will just break his python installation without
> > and it can make things complicated if two packages need different APIs.
> If two packages need two different versions of a third package, then
> your project is in trouble, api differences or not...
Your project is in trouble because of the total absence of API
management. Otherwise there’s no reason why you couldn’t have some
dependencies use one API and some other dependencies an other one.
But the problem is worse than that: you know, there’s not only one
application installed on a system. If one project needs one version and
the other project another, incompatible version, you cannot install both
on the same system.
> > I showed already two examples: versioned provides and exact
> > dependencies.
> I don't know what either of these terms means I'm afraid :-S
Versioned provides mean "module bar at version 1.2 provides
functionality of module foo at version 1.0".
Exact dependencies mean "module bar at version 1.2 requires module foo
at version 1.0 *and only this version*."
: :' : 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
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
More information about the Distutils-SIG