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 =).
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
