-------------------------------------------- On Thu, 30/1/14, Paul Moore <p.f.moore@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