Re: [Distutils] nspkg.pth files break $PYTHONPATH overrides
On Tue, Mar 25, 2014 at 3:50 PM, Barry Warsaw wrote:
> On Mar 25, 2014, at 03:35 PM, PJ Eby wrote:
>
> >I think the correct fix would be to change the nspkg.pth magic to check
> for
> >PEP 420 support, but unfortunately it seems we may have to use version
> >checking: on rereading PEP 420 I see there's no 'sys.namespace_packages'
> or
> >similar object that can be directly checked for feature support. :-(
>
> There is. It's *pronounced* sys.namespace_packages, but it's spelled
> importlib._bootstrap._NamespaceLoader ;)
>
Yeah, well that's not exactly a public attribute, so it's not necessarily a
great way to do it. But if we did use that, presumably it'd add something
like:
hnp =
hasattr(sys.modules.get('importlib._bootstrap',None),'_NamespaceLoader');
To the front of the magic, and then prefix all subsequent expression values
with 'not hnp and' in order to prevent them executing if PEP 420 support is
available. (Note: it's checking sys.modules since on any interpreter where
PEP 420 is natively available, the module should *already* be loaded by the
time site.py does its thing.)
And we should probably think about adding sys.namespace_packages or
something of the sort, or at least a proper flag for whether PEP 420
support is available on the platform.
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] nspkg.pth files break $PYTHONPATH overrides
On Mar 25, 2014, at 03:35 PM, PJ Eby wrote: >I think the correct fix would be to change the nspkg.pth magic to check for >PEP 420 support, but unfortunately it seems we may have to use version >checking: on rereading PEP 420 I see there's no 'sys.namespace_packages' or >similar object that can be directly checked for feature support. :-( There is. It's *pronounced* sys.namespace_packages, but it's spelled importlib._bootstrap._NamespaceLoader ;) http://youtu.be/ehKGlT2EW1Q?t=44s Cheers, -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] nspkg.pth files break $PYTHONPATH overrides
On Mon, Mar 24, 2014 at 6:09 PM, Barry Warsaw wrote: > On Mar 24, 2014, at 05:53 PM, Donald Stufft wrote: > > >See also https://github.com/pypa/pip/issues/3 > > Hah, yeah. I didn't realize --single-version-externally-managed is > implied by > --root, and in fact our Debian build scripts often (either explicitly or > implicitly) define --root, as is the case in lazr.uri. > > >Basically prior to PEP420 namespace packages were bad and using them > results > >in pain sooner or later :( I'm not sure if a good solution yet, perhaps we > >can backport PEP420 to PyPI and have namespace packages depend on that? > > Or maybe do a version check before installing this file? Python 3.3 and > newer > will have PEP 420 support, and this file makes no sense in that case. > That won't *quite* work, because the .pth files are generated for other types of direct-install distributions. I think the correct fix would be to change the nspkg.pth magic to check for PEP 420 support, but unfortunately it seems we may have to use version checking: on rereading PEP 420 I see there's no 'sys.namespace_packages' or similar object that can be directly checked for feature support. :-( ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] nspkg.pth files break $PYTHONPATH overrides
On Mon Mar 24 2014 at 6:09:48 PM, Barry Warsaw wrote: > On Mar 24, 2014, at 05:53 PM, Donald Stufft wrote: > > >See also https://github.com/pypa/pip/issues/3 > > Hah, yeah. I didn't realize --single-version-externally-managed is > implied by > --root, and in fact our Debian build scripts often (either explicitly or > implicitly) define --root, as is the case in lazr.uri. > > >Basically prior to PEP420 namespace packages were bad and using them > results > >in pain sooner or later :( I’m not sure if a good solution yet, perhaps we > >can backport PEP420 to PyPI and have namespace packages depend on that? > > Or maybe do a version check before installing this file? Python 3.3 and > newer > will have PEP 420 support, and this file makes no sense in that case. > > (Backporting PEP 420 support to Python 3.2 might be useful, though a pain > without importlib. There's no sense in backporting to Python 3.1, IMHO.) > Importlib is in Python 3.2. You would just need to do the right things to set up the environment and set __import__ to avoid doubling the stat calls on a failed import. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
