On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 25 August 2013 23:14, PJ Eby <p...@telecommunity.com> wrote: >> >> > Unless I'm missing something, I suspect that this over-counts the number >> > of >> > people using multi-version, in the sense that many (the majority?) of >> > wrapper scripts using multi-version do not actually need to,because the >> > users never install more than one version. And quite likely don't even >> > know >> > that they could. >> >> That's just it: if you install two programs, one of which needs >> CherryPy 2 and the other CherryPy 3, then with easy_install this just >> works, without you having any idea that you even have more than one >> version installed, unless you for some reason choose to look into it. >> >> Thus, you don't have to know you have multiple versions installed; it >> can trivially happen by way of dependencies you aren't paying >> attention to. The more things you install, the more likely it is you >> have two versions hanging around. > > > OK, I see. But I'm not sure if we're agreeing or disagreeing over the > result. To me, this is a bad thing on the principle that there is a cost to > multiversion support (it's not part of core Python, so you have to do > *something* to make it work) and so having people inadvertently pay that > cost to use a feature that they don't actually *need* is wrong. An opt-in > solution is fine, as in that case the user has to choose to use > multiversion, and if they don't want to they can choose an alternative > approach that they accept the cost of (for example, running their one > CherryPy 2 using application in a virualenv). > > One other point, just as a matter of curiosity (because it's not relevant to > the current discussion): in your explanation above, there doesn't seem to be > any step that says the user normally uses CherryPy 3 (so that would be the > one they would get automatically at the interactive interpreter). For me, > that's really the only use case I'd have for multi-versioning - 99% of the > time I use a particular version of a project, but I have one particular > application that can't work with the version I prefer. > > Paul
It is important to at least give the "unpacked wheel file that is added to sys.path" a different name. The format is designed to give different names to different things. I would like to see some consideration given to what Ruby and npm do, which is to place what we are calling dists into a special directory that only contains dists /somedir/distname-1.0/... rather than placing them as specially named objects on the normal search path. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
