Tarek Ziadé a écrit : > On Fri, Oct 9, 2009 at 2:43 PM, kiorky <kio...@cryptelium.net> wrote: >> Hi tarek, >> >> Tarek Ziadé a écrit : >> >>> The *whole* point of Distribute 0.6.x is to be backward compatible, meaning >>> that if virtualenv switch to it, you will not even notice it. >> Living in my 0.6.x snail sandbox is not a solution. >> As it seems that Distribute 0.7 won't for a long time. >> >> "setuptools based" packages will be able to be installed via the distribute >> 0.6 >> branch but not compatible with "distribute based" stuff. Note that new things >> will eventually be packaged with the "new good way todo, aka with 0.7". >> There is >> a great risk that they can't live together aside. NOGO > > Why they can't ?
As i understood all those readings, packages for 0.6 and 0.7 will be installable with the appropriate distribute version, thus side by side, but for me, they may be incompatibles together. > >> 0.7 packages wont be compatibles with setuptools installation/namespaces, so >> it >> will be impossible to install a lot of "setuptools based" packages aside with >> new stuff in with this way too. NOGO too. > > Why will it be impossible ? pep-0382 is not equivalent to setuptools's one for example. Can i have been certified i will not have breakages when trying to import a setuptools based namespace package from a 0.7 sharing the same namespace? > > [...] >> I appreciate what you folks are doing with the distribute sphere, i have not >> that much problems with it, but i do not support that it breaks very badly >> the >> retro compatibilty for all things already packaged today, today tomorrow or >> in >> one year. > > Again, you will be able to use 0.6 and 0.7 together. or 0.6 alone, or > 0.7 alone. > > Nothing will be broken in a distribution that uses 0.6. > > 0.6 stays maintained. As i said ealier, there will be incompatibilities at some point. And also, to use them together, what a hell. For package A i need 0.6 (hard requirement), for package B i need 0.7 (hard requirement), for C i need 0.6. C depend on A which depends on B. I also have no sort of control over the maintenance of those products, think that the authors are dead. So, i ll have to manually install B for A to fulfill its requirements then C will install. Deployments will be simple :) > > Tarek -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
