----- Original Message ----- > On Wed, Mar 20, 2013 at 1:01 AM, Bohuslav Kabrda <[email protected]> > 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). >
Yep, it's backwards incompatible, sure. I think your proposal is a step in the right direction. My proposal is where I think we should be heading in the long term (and do the big step of breaking the backward compatibility as a part of some other huge step, like Python2->Python3 transition was). As for Linux distros, that's not an issue AFAICS. We've been doing the same with Ruby for quite some time and it works (yes, with some patching here and there, but generally it does). Fact is that this system brings lots of benefits to developers. I'm actually quite schizophrenic in this regard, as I'm both packager and developer :) and I see how these worlds collide in these matters. From the packager point of view I see your point, from the developer point of view I install CherryPy 4, import CherryPy and then find out that I'm still using version 3, which breaks my developer expectations. > 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 | [email protected] | Brisbane, Australia > -- Regards, Bohuslav "Slavek" Kabrda. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
