Please add ~/.local/bin to the default $PATH
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bash (Debian) |
Fix Released
|
Unknown
|
|||
bash (Ubuntu) |
Fix Released
|
Medium
|
Matthias Klose | ||
Xenial |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Starting in Xenial, 'pip install' by default places executables into ~/.local/bin. This is the de-facto standard place to put per-user executables -- for example, Fedora/Redhat puts it on the $PATH by default, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts.
But unfortunately, Ubuntu's does *not* add this directory to $PATH by default, which means that 'pip install' doesn't actually work -- any scripts that are installed are inaccessible, and every user has to manually add this to their PATH.
Ubuntu should put ~/.local/bin onto PATH by default.
Minor details (discussed with @doko at the PyCon sprints):
- this should go at the beginning of PATH rather than the end, in accordance with Debian policy saying that more-local paths go before more-upstream paths. (This is inconsistent with how Fedora/RH do it, but consistent with how Python itself searches for packages.)
- this will be added to /etc/skel/profile, so that it won't change any existing user accounts; it will only be applied to user accounts created *after* this change lands
- unlike ~/bin (which Debian/Ubuntu have supported for ages), it will be added to PATH unconditionally, even if the directory doesn't exist. This is important to avoid a nasty trap for new users, where the first time they try to install a Python package they have to restart their shell. Since this only applies to new accounts, the directory will always start out nonexistent/empty, so having it in $PATH won't cause any unexpected changes in behavior.
- possibly it would make sense to set this in /etc/environment or /etc/skel/.gnomerc or similar, so that it would also apply to non-shell processes (e.g. if the user wants to add a global key-binding to launch a Python program, then generally ~/.profile *doesn't* affect the environment where this command gets executed, and that can frustrate and confuse users if a command works fine from the terminal but not from a keybinding). But we should defer this discussion for the future, because even if this is a good idea, it isn't a good idea in a Xenial stable update.
Debian bug: https:/
Changed in bash (Debian): | |
status: | Unknown → New |
Changed in bash (Debian): | |
status: | New → Fix Released |
Changed in bash (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in bash (Ubuntu): | |
importance: | Undecided → Medium |
Status changed to 'Confirmed' because the bug affects multiple users.