[Distutils] "just use debian"

[Josselin Mouette]

Le mercredi 01 octobre 2008 à 17:24 +0900, David Cournapeau a écrit :
> I mean, when I build my C program against the glibc, I never have to
> change my compiler commands depending on which version of glibc I want.

Indeed, and the reason is that *functions never disappear from the
glibc*.

> Internally, this is handled by versioned sonames, at the link and load
> stage, yes, but only because it is "easy" to do and doable for C,
> because the library itself is never referenced in the code; IOW, there
> is the link process in C and similar compiled languages which use the
> name changes. But other languages use something different; I don't claim
> any deep understanding of the scheme, but mono uses a totally different
> scheme to handle versioning:
> 
> http://www.mono-project.com/Assemblies_and_the_GAC
> 
> Does mono cause problems to debian ? I think this kind of system is much
> more adapted to python than the C model is, because C has this two steps
> thing that python does not have.

I don’t think Mono causes issues, but I’m pretty sure that allowing
multiple versions like the GAC allows *will* causes issues. Not for
purely-packaged things, where you can safely ignore those directory
renames, but if you start mixing distributed packages and
user-downloaded stuff, they will run into the same issues we have with
setuptools.

> Of couse, it is more complicated than changing names. But I fear that
> people wants their cake and eating it: you can't have well maintained
> packages and reliability without thinking about API/ABI issues. There
> has to be a balance between OS distributors need (mostly only one
> version) and other people needs who may need several parallel
> installations.

Changing name is the only thing that is available at the language level,
currently. Everything else that comes on top of it is a pile of gross
hacks. If you really want something better, with e.g. a name and an API
version, you need to convince the core python developers to introduce
such functionality in the interpreter itself. Something that allows to
say "import foo with apiver 2 minver 2.1".

> I think setuptools and the whole eggs thing makes it well too easy to
> install several versions at the same time, making some people naively
> thinking it solves the dependency issues, without thinking that it
> replaces a kind of dll hell by a dependency hell. But OTOH, as a
> developer, I need to be able to develop my packages, distribute them,
> and breaking them from time to time before I reach 1.0. That's almost
> requirement of open source development, at least if you follow the
> release early/release often.

C developers have already solved these kinds of issues, and they no
reason why you can’t do the same: keep the modules private until they
are deemed stable, introduce deprecation warnings long (and I mean two
years, not two weeks) before API breaks, require other developers to use
e.g. specific flags to access unstable API, etc. They are all
compromises, because there is no silver bullet for dealing with these
issues. And setuptools is not a silver bullet either, except for
shooting yourself in the foot.

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