On 29 January 2014 23:59, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
goes further than the current EXTENSIONS approach - this proposal would be akin to *requiring* an empty EXTENSIONS file, and/or the setuptools zip_safe flag in order to allow mounting of even the pure Python wheel. Such a conservative approach is also the antithesis of the setuptools "attempt to guess": if the package publisher doesn't explicitly opt in to zip support, then distlib.mount would assume that it is *not* supported (but may provide an API for the caller to override that, like "assume_zip_safe=True" or "force=True").
I have no problem with adding wheel metadata to allow/disallow even adding to sys.path - it's effectively just like another step in the compatibility check. It would make most sense to place this in the WHEEL metadata, rather than pydist.json or similar, since it relates to the contents of a particular wheel rather than the distribution in general.
Oh, an "Import-compatible" flag in the WHEEL metadata? Yeah, I like it. Noted as an issue for wheel 1.1: https://bitbucket.org/pypa/pypi-metadata-formats/issues?component=Wheel
However, like Paul, I have some concerns about a still experimental API like that being in the metadata 2.0 reference implementation, since that will likely end up having to deal with stdlib-like levels of backwards compatibility requirements, and removing experimental APIs that we later decided we weren't happy with could prove problematic.
But we're talking about the Python 3.5 time-frame here, and 3.4 isn't even out yet. ISTM there is plenty of time to get these sorts of issues ironed out. While I tend to favour backward compatibility wherever possible, distlib is nowhere near 1.0, and so distlib users (a small number, from what I can see) could expect some API breakage if there's no sensible alternative.
Yeah, I think I'm just nervous because sitting down and properly reviewing the distlib API is somewhere in the middle of a gigantic todo list :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia