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

[bitdancer]

BPO	20071
Nosy	@ncoghlan, @ned-deily, @bitdancer, @dstufft

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = [] title = 'What should happen if someone runs ./python -m ensurepip in the build environment?' updated_at = user = 'https://github.com/bitdancer' ``` bugs.python.org fields: ```python activity = actor = 'ncoghlan' assignee = 'none' closed = False closed_date = None closer = None components = [] creation = creator = 'r.david.murray' dependencies = [] files = [] hgrepos = [] issue_num = 20071 keywords = [] message_count = 3.0 messages = ['206948', '226573', '226574'] nosy_count = 4.0 nosy_names = ['ncoghlan', 'ned.deily', 'r.david.murray', 'dstufft'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = None url = 'https://bugs.python.org/issue20071' versions = ['Python 2.7', 'Python 3.4', 'Python 3.5'] ```

[bitdancer]

Someone on IRC reported doing this, and it (logically enough) gave a permission error trying to install into /opt. That may be exactly what it should do...but if he'd done it as root, presumably it would have tried to install PIP without python having been installed first, which might be wrong.

(Donald says it would indeed install it, creating the directories as needed.)

[ncoghlan]

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.

[ncoghlan]

Note that if I find time to implement the startup sequence redesign for PEP 432/issue bpo-22257 (which is finally starting to look like it may actually happen some time in the next few months), a proper fix may end up being possible for 3.5.

We shouldn't bet on that, though, and the explicit failure is definitely the best we'll be able to do for 3.4 and the 2.7 backport.