[Distutils] Multi-version import support for wheel files

[PJ Eby]

On Mon, Aug 26, 2013 at 5:20 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 25 August 2013 23:14, PJ Eby <pje at telecommunity.com> wrote:
>> 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)

Seriously?  The basic functionality of using sys.path to have multiple
versions *is* part of core Python, and has been since 1.5.2 (16 years
ago), and probably longer than that.

In the days before easy_install and virtualenv, if you needed
different versions of things, you used "setup.py install" to different
directories (assuming distutils was involved, otherwise you just
copied files) and either put your scripts in the same directories, or
used PYTHONPATH or explicit sys.path manipulation.

That is all easy_install does: add a naming convention for the
directories, and automate the sys.path manipulation.

Buildout does the same thing, it just writes the sys.path manipulation
into the scripts statically, instead of using pkg_resources at
runtime.

So the notion of "cost" doesn't make any sense.  Tools like
easy_install and buildout *reduce* the management cost, they don't add
anything to core Python.

(Now, if you're talking about the .pth files from easy_install, those
are something that I added because people complained about having to
use require(), and wanted to have a default version available in the
interpreter.)


> and so having people inadvertently pay that
> cost to use a feature that they don't actually *need* is wrong.

What cost are you talking about here?  Given that most people don't
even know they *have* multiple versions installed or care, how is a
cost being imposed upon them?  Are you talking about disk storage?


> 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).

If they easy_install that version, sure, that's what they'll get as a
default version.


> 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.

Yes, and that's the sort of scenario Nick was proposing pip support,
that you have an explicit "install me a different version for my other
app" capability -- such that that app's script wrapper adds its
alternate version to sys.path ahead of the default one.  So it would
have been opt-in and impose the "cost" of a slightly longer sys.path
and increased disk space usage only on those who ask for it.

(Honestly, 90% of this entire thread has sounded like complete FUD to
me, i.e. fear based on a lack of understanding that there actually
isn't anything magical about multi-version support.  As Jim has
pointed out, buildout does multi-version support without even using
pkg_resources.  And before all these tools existed, people just
installed things in different directories and used either adjacent
scripts, PYTHONPATH, or explicit sys.path manipulation.  There is
nothing magical whatsoever about having multiple versions of a thing
installed on your system; all the tools do is add naming conventions
for where stuff is installed...  and having such naming conventions is
a *good* thing, compared to the old days.)