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.
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
