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