[Distutils] "just use debian"

[David Cournapeau]

Josselin Mouette wrote:
>
> Indeed, and the reason is that *functions never disappear from the
> glibc*.

Yes and no. If you remove a function, you're indeed screwed, because you
can't handle versioning in the header. But you can handle versioning in
libraries at the link step, and file name of the library is an
implementation detail of this versioning.

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

Please read the article carefully, it is not only about the GAC. It does
handle the two conflicting issues: API stability installed globally vs
easiness of deployment. That's why it is an interesting read IMHO: it
addresses both issues. I don't think there is a single chance to see
something as strong as C for python, because it would severely undermine
the whole idea of the language used for prototyping.

>
> 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".

Yes, that's exactly what I am saying. But that's the only solution in
the long term I can see. Setuptools and co will never be usable for
robust deployment: it kind of works for simple cases, or for developers
who know what they are doing. But it is inherently unable to handle more
complicated cases.

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

Again, this is pipe-dream. You can do that for C because it is a dead
language (dead in the sense not evolving). Python is not like that.
Changing python philosophy has zero chance of success. How many
languages appeared after C do like C ? I don't know many.

cheers,

David