[issue20071] What should happen if someone runs ./python -m ensurepip in the build environment?

Nick Coghlan report at bugs.python.org
Mon Sep 8 13:47:39 CEST 2014


Nick Coghlan added the comment:

The whole sys.path initialisation scheme is pretty broken when running from a source checkout, so the short answer is "it won't work, and it isn't really fixable in a maintenance release".

System Python 3:

sys.path = [
    '/home/ncoghlan/devel/py3k',
    '/usr/lib64/python33.zip',
    '/usr/lib64/python3.3',
    '/usr/lib64/python3.3/plat-linux',
    '/usr/lib64/python3.3/lib-dynload',
    '/home/ncoghlan/.local/lib/python3.3/site-packages',
    '/usr/lib64/python3.3/site-packages',
    '/usr/lib/python3.3/site-packages',
]

My source checkout:

sys.path = [
    '/home/ncoghlan/devel/py3k',
    '/usr/local/lib/python35.zip',
    '/home/ncoghlan/devel/py3k/Lib',
    '/home/ncoghlan/devel/py3k/Lib/plat-linux', 
    '/home/ncoghlan/devel/py3k/build/lib.linux-x86_64-3.5',
    '/home/ncoghlan/devel/py3k/Modules',                
    '/home/ncoghlan/.local/lib/python3.5/site-packages',
]                                                                                                                

We should probably have an explicit check for that in ensurepip so it bails out as an unsupported operation rather than doing something weird. Looking in sys.path for "os.path.join(os.path.dirname(sys.executable), 'Lib')" should be a fairly reliable indicator that we're running from a source checkout.

Actually *fixing* it to do something sensible would require a lot of work on the sys.path initialisation code, and I frankly consider that impractical given the current state of getpath.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20071>
_______________________________________


More information about the Python-bugs-list mailing list