Josselin Mouette wrote: > > As I understand PEP 345, it proposes to introduce dependencies based on > module names, not on project names. This is one of the key points where > it is superior to setuptools; especially, if developers correctly change > the module name when changing the API, the dependencies are clear and > reliable.
I don't understand this. Why do you need to change the module name ? You need to be able to request a given version of the module, yes, but you don't need to change the name itself. Changing name is an implementation detail of the concept of retrieving a particular version, no ? 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. 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. 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. 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. cheers, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
