On Wed, Mar 20, 2013 at 1:01 AM, Bohuslav Kabrda <bkab...@redhat.com> wrote: > So what would be done when CherryPy 4 came? CherryPy 3 is installed directly > in site-packages, so version 2 and 4 would be treated with split-install? > It seems to me that this type of special casing is not what we want. If you > develop on one machine and deploy on another machine, you have no guarantee > that the standard installation of CherryPy is the same as on your system. > That would force developers to actually always install their used versions by > "split-install", so that they could make sure they always import the correct > version.
This approach isn't viable, as it is both backwards incompatible with the expectations of current Python software and incompatible with the requirements of Linux distros and other system integrators (who need to be able to add new backwards incompatible versions of software without changing the default version). And I definitely won't shout at people for mentioning what other languages do - learning from what works and what doesn't for other groups is exactly what we *should* be doing. Many of the features in the forthcoming metadata 2.0 specification are driven by stealing things that are known to work from Node.js, Perl, Ruby, PHP, RPM, DEB, etc. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
