Just an FYI, I've begun compiling notes and plan on proposing PEPs that will be aimed at supplanting PEP 425 and PEP 427 with the goal of nailing down undefined behavior, including missing functionality, and removing misfeatures.
On Jan 30, 2014, at 10:56 AM, Daniel Holth <dho...@gmail.com> wrote: > I see you've noticed wheel was released in an imperfect state. > > Let's add a Zip-Safe flag to the WHEEL file, values of "true" and > "false" same as Root-Is-Purelib. > > Daniel > > On Thu, Jan 30, 2014 at 10:44 AM, Eric V. Smith <e...@trueblade.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 01/30/2014 10:23 AM, Donald Stufft wrote: >>> >>> On Jan 30, 2014, at 10:12 AM, Paul Moore <p.f.mo...@gmail.com> >>> wrote: >>> >>>> On 30 January 2014 15:03, Donald Stufft <don...@stufft.io> >>>> wrote: >>>>> For those following along at home who have no interest in >>>>> supporting zipped Wheels who want to disclaim support for it, >>>>> here's how you do zip_safe=False for Wheels: >>>>> https://gist.github.com/dstufft/8710270. >>>> >>>> Note that this will also prevent use in py2exe, cx_Freeze and >>>> any similar bundling technologies. Presumably that's what you >>>> want, as any issues are identical, but it's worth being clear. >>>> >>>> Paul >>> >>> Sure, using a library via zip import when it wasn't designed to be >>> used as such is an anti pattern. >> >> The flag really needs to convey 2 meanings: >> - - There are some C extensions here that can't be loaded unless they >> live on a real filesystem path. >> - - There is some code (maybe in this package, maybe in another package >> that uses this one) that uses this package's __file__, and that code >> won't work unless __file__ points to a real filesystem path. >> >> There are any number of possible importers that would fail due to >> these 2 cases. I've personally written one that loads modules from a >> database. It should respect this flag, too. >> >> Which is a long way of saying: I think calling it "zip_safe" is a >> misnomer. The flag is really conveying "I don't need to be on a >> filesystem". >> >> Whether there should be 2 different flags for the two different >> problems (C extension and __file__), I can't say. They do seem to go >> hand-in-hand. >> >> Eric. >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.14 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJS6nNFAAoJENxauZFcKtNxgYgH/RG1OKUDEgg9NSR2XH/9Uuw6 >> N+MrbQtPPErcyQS3OWCpat4wHiJgOy+oyJR8E3fbJBJpV72csJZBhC0jghiy1fnO >> l1T72084cri7X4LzfApF84N35czaCU1V1f3/ju9cpMqO5DKJMjeHu7RFdvcHq7hv >> a5/7/zwxPeOpl/wuQe3YODT0x+IQjQsQsvhj1S2m7zHtPQUYlYSvhuTOkKE1snqD >> /t5ryU2+HoywKPlITU6dkHEb6/cN8ZDFnbi5gUWXh2URGic6I52A/mfQwtItr0eN >> 1GnySV6Mbbgdwa7UznhXKnIuCLwqmB6D8zOVNBtOPXKMMuQuKL1IRT1aNppuS8Y= >> =6tIo >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
