[Distutils] Multi-version import support for wheel files

[Daniel Holth]

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