On Thu, Jul 11, 2013 at 11:50 AM, Brett Cannon <br...@python.org> wrote:
> > > > On Thu, Jul 11, 2013 at 10:52 AM, Donald Stufft <don...@stufft.io> wrote: > >> >> On Jul 11, 2013, at 10:47 AM, Brett Cannon <br...@python.org> wrote: >> >> I'm just not seeing the downside. We control the stdlib and pip, so we >> know the expected interaction and we are purposefully using the override >> mechanics so it's not going to get messed up by us if we consciously use it >> (and obviously have tests for it). >> >> >> I don't think it's especially a problem for pip. I think Daniel was just >> speaking how the behavior you suggested we could exploit to make this >> happen has been a major issue for namespace packages in the past using the >> other methods. >> >> However I'm not sure how it's going to work… python -m pip is going to >> import the pip namespace package yes? And then when pip is installed it'll >> shadow that, but in the original process where we ran python -m pip won't >> the namespace package have been cached in sys.modules already? >> > > Yes, but you can clear it out of sys.modules before executing runpy to get > the desired effect of falling through to the regular package (runpy > wouldn't import pip.__main__ so you literally just need ``del > sys.modules['pip']``). You could also pull the old pkgutil.extend_path() > trick and use the append method on the _NamespacePath object to directly > add the new directory that pip was installed to and then import > pip.runner.main(), but that feels like more of a hack to me (but then again > I'm rather comfortable mucking with the import system =). > And if you're still worried you can always invalidate the cache of the finder representing the parent directory pip got installed to (or all finder caches if you really want to get jumpy).
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
