[Distutils] Multi-version import support for wheel files

[Paul Moore]

On 25 August 2013 14:07, Donald Stufft <donald at stufft.io> wrote:

> As far as I can tell there's nothing preventing Installing a Wheel *into*
> and .egg
> directory which will give you exactly the same situation as you have today
> without needing to do *anything* except make a tool that will install a
> Wheel
> into an .egg directory. This solves your immediate desire without hanging
> more things onto Wheel.
>

I think that relating this to wheels is a mistake. As Donald says, wheels
are just a distribution format.

Looking at this from a different perspective, I don't see any immediate
issue with being able to install distributions outside of site-packages.
That's what pip's --target option does. It seems like the multi-versioning
support that is being discussed is nothing much more than a means of
managing such "not on site-packages" directory in a way that allows them to
be added to sys.path at runtime.

On that basis, I don't have an issue with the idea. It's supported in pip
(via --target) already, and the runtime aspects can be handled in
pkg_resources or wherever without affecting me.

If, on the other hand, there is a proposal in here to change pip, then (a)
I'd like to see what the explicit proposal is before commenting, (b) it
should apply equally to all means by which you can install using pip (wheel
and sdist - AFAIK --target has no meaning for --develop installs, and the
same should be true here), and (c) it should not need any changes to the
wheel format (again, I see no indication that it does, but I'd like to see
that explicitly stated).

The key point here is that I *don't* want wheel associated with all of the
extra baggage that goes along with the egg concept. Even putting wheels on
sys.path gives me a nervous feeling that we're reinventing eggs. I feel
strongly that wheel is inventing bdist_simple rather than egg, and should
continue to do so.

As regards Nick's proposal:

1. "An option (or options) to pip, telling it to just drop a wheel file (or
the unpacked contents of the wheel as a directory) into site-packages
instead of installing the distribution directly as the default version."
Well, if it's in site-packages, it *is* importable/installed. That's how
site-packages works. So I don't understand what "instead of installing"
means. But if --target does what you want then go for it. If you want
something different then I think it's likely a bad idea, but I'd need
details of how it would work to be sure.

2. "Support for the ".whl" filename format and internal layout in
pkg_resources".
No, very definitely -1. The wheel format is a *distribution* format and
pkg_resources is a *runtime* mechanism. Misxing the two is the key mistake
(in my mind) that setuptools made, and we do not want to do so again. If
you need a multiversion runtime layout for pkg_resources, then let's define
it in a PEP, and write installers to put packages into that format if we
need to. But let's not just reuse wheel as that format - that was not its
intent. If a distribution format better than wheel comes along in the
future, we should be able to replace it without needing to break everyone's
runtime code because pkg_resources doesn't know wbout it.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130825/673c97ce/attachment.html>