On the one hand, it's easy to see the allure of a zipimport-able format. Grab a file, import it, use functionality straight away. It has an attraction of self-containedness. On the other hand, python's dynamic nature means that things are not as simple as Java jar's as Donald points out. I agree that wheels shouldn't officially support this feature wholesale. However, perhaps they could do so conditionally? E.g. designate some mechanism by which it is possible to inspect a wheel and determine that it intends to explicitly be zipimport compatible. A prime candidate would be that the wheel is of a purelib in nature, another would be to add a top-level file or metadata indicating such (e.g. '.zipimportable'). But other wise I agree that we should explicitly seek to avoid any language that could lead users to expect this functionality of wheels wholesale in any way, even though they happen to be regular zip files. On 29 Jan 2014 17:09, "Donald Stufft" <don...@stufft.io> wrote:
> > On Jan 28, 2014, at 11:14 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > > Donald Stufft <donald <at> stufft.io> writes: > > > >> I think we need to reconsider this. I cannot stress how badly an idea > >> I think it is for Wheels to concern itself with the ability to add the > >> Wheel to sys.path and import it. > > > > I know that people have had bad experiences in the past with eggs, for > the > > reasons Nick outlined in his response. However, you don't say *with > > specifics* why you think putting wheels on sys.path is a bad idea - I > don't > > think it's convincing enough just to hand-wavingly reference problems > with > > the egg format. > > > > When this topic came up before, I asked for specific failure modes which > > were causing concern, but I never got a response IIRC. > > > > One can't say that having the same packaging and importable formats is > > inherently bad, since Java shows otherwise. So if there are specific > > problems, they should be identified. > > Last time this topic came up Jim Fulton did point things out. > > 1. That unpacking into the home directory is problematic because users > that run services often don't have home directories. This you waved > away by saying that the home directory isn't a required place, to which > Jim responded that unpacking them anywhere else was likely to have > access control / security issues and "generally cause pain". Which I > wholly agree with, intact Mitre has assigned CVE's to applications that > did switch their Egg Cache to directories other than HOME. > > 2. Zipped Eggs are more difficult to work with for debugging purposes, > which > you responded saying that Wheels are a "deployment format" (which I > don't believe is supported by the PEP at all) and Jim responded with > his > experience in developing against things that got installed as zipped > Eggs > and the pain that has personally caused him. > > 3. Zipped imports (In Jim's experience) are slower than unpacked imports, > which you replied (quite literally) "Caveat emptor". Jim's response > was that > this had been tried with Egg and had been found to be more pain than it > was worth. In his exact words: > > "It's been tried with eggs. This is not new ground. Encouraging people > to > do this is going to cause pain and resentment. > > I think one of the reasons there's so much (IMO mostly irrational) > hate for > eggs is that people think you can only used zipped eggs, and zipped > eggs > cause pain and agony." > > He closes up with, > > "Importing from zipped eggs has proved itself to be an anti pattern. > > Buildout (as of buildout 2) always unzips eggs." > > So you have pip that doesn't use zipped Eggs, buildout which made sure > in buildout 2 (presumably drawing from the lessons of buildout 1) to always > unzip eggs, and easy_install which does support zipped eggs (sometimes, > if it thinks that particular Egg will support it). > > Why do we insist upon repeating the mistakes of the past? > > > > >> Further more it won't even work accurately for all Wheels (as Nick's > >> edit says) so we require that people wanting to do this figure out if > >> their Wheel can or can not be added to the sys.path (which isn't as > >> simple as looking at the tags because a platform specific Wheel may only > >> contain optional C modules). > > > > I don't yet see a technical impediment here. For example, distlib's wheel > > implementation uses a "mount" method to add a wheel to sys.path. This > uses > > the tags to check for compatibility - there's no "figuring out" that the > > user has to do. If additional metadata about C extensions is available > > (which it is, if the wheel is built from source using distil), then those > > extensions are made available for import, too. I realise that's an > extension > > to the current spec, but then no one is forcing any one to use it. > > Zipped Eggs have a long long history of causing very weird failures > conditions, > you say your Wheel.mount checks for compatibility, does it also check that > the library to be installed isn't using __file__ shenanigans instead of > pkgutil.get_data()? easy_install tried to do this with varying degrees of > success, > I've never seen much except pain from zipped Eggs. > > > > > Regards, > > > > Vinay Sajip > > > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > https://mail.python.org/mailman/listinfo/distutils-sig > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
