[Distutils] wheels on sys.path clarification (reboot)

[Vinay Sajip]

--------------------------------------------
On Thu, 30/1/14, Paul Moore <p.f.moore at gmail.com> wrote:

> This is the biggest concern I see with "promoting" wheels
> being directly importable via zipimport (I say "promoting" and
> not "specifying" deliberately, but I don't want to get back into
> the process debate).

In my view, we can have our cake and eat it. Those who don't want
their wheels to be mountable can say so in their wheel metadata. I
expect that distlib will honour such metadata (once the details have
been worked out) and not mount wheels which aren't supposed to
be mounted. However, it's perfectly easy to write code that runs
from zip, as long as you know that's a deployment option you want
to support. So it doesn't make sense to prevent that useful
functionality - even pip is using it, I believe ;-) - just because some
people think it's a bad idea, for reasons that are hardly compelling.
To say that we should keep packaging separate from importing is
in some sense a religious argument, unless sound technical
reasons are given for it. Java proves otherwise otherwise - and
for those who hate Java, that's a religious viewpoint, too ...

The argument that importing wheels will cause problems is trumped
by allowing the mountability to be configurable by wheel metadata:
the builder of a wheel, by saying it is mountable, is agreeing to all
that entails in terms of handling package resources appropriately,
etc. So the support burden shifts to them, and not to wheel, distlib or
any packaging tool.

So much heat over process, but so little light over exactly why
*appropriately designed* software deployed in wheels shouldn't be
importable. No detailed analysis of any problem with wheels taking
into account the differences from eggs (the things Daniel mentioned
in the other thread "problems with eggs?", plus the fact that there's
no sys.path manipulation *magic*). Just blanket statements to the
effect that "eggs were importable and bad, so wheels must be too"
smacks of superstition, not engineering.

I would like the detractors of importable wheels to put their
technical reasoning on the table, not use process debates to try to
revert situations they're not happy with. That technical reasoning
should address wheels as they are now and avoid referring to eggs
as the bogeyman.

The only reason I've heard from detractors so far is that software
not designed to run from zip can give unexpected results when run
from zip, which could give the wheel format a bad name. Given that
a wheel publisher can have a say on importability, this issue seems
to me to be adequately addressed. No detractor has come up with
any other solid reasoning as to why the useful feature of wheel
importability is bad. I invite them to put up, or ... we'll still be in the
dark the next time this debate comes around ;-)

Regards,

Vinay Sajip