Package: bash Version: 4.3-14+b1 Severity: normal ~/.local/bin is a de-facto standard place to put per-user executables -- for example, Fedora automatically places it on the $PATH, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts (and therefore, this is where 'pip install --user ...' puts scripts).
Unfortunately, Debian's does *not* add this directory to $PATH by default, which means that 'pip install --user' doesn't work. Indeed, Debian doesn't add any per-user directories to $PATH unconditionally -- all it does is add ~/bin if ~/bin exists. So even if pip started dropping binaries into ~/bin, you'd still have the awful new user experience of having to restart your shell after running 'pip install --user' for the first time. Plus, I think everyone would agree that it would be Rude for pip to automatically create a visible directory in $HOME. ~/.local/bin is a much better place for automated tools like this. So this seems like something that Debian has to fix in /etc/skel, not something that pip can fix on its own. (Unless pip starts editing individual user's ~/.profile files, I guess.) In addition, the fact that ~/.local/bin is missing from the Debian/Ubuntu default $PATH means that the obvious 'pip install --user <package>' approach does not work for lots of users; this is one reason that upstream documentation tends to recommend 'sudo pip install <package>' -- unlike --user, it actually works. I think we all agree that 'sudo pip' is an abomination, and we want upstream documentation to stop recommending it; adding ~/.local/bin to $PATH makes it much easier to get upstream on board with this and kill 'sudo pip'. Therefore, I suggest that ~/.local/bin should be added to the default $PATH on Debian. There are a few minor details about how to do this. One question is whether it should be added at the end or the beginning of $PATH. Fedora adds it at the end -- specifically, their /etc/skel/.bash_profile has the line: PATH=$PATH:$HOME/.local/bin:$HOME/bin But IMO this is unfortunate, because if I just installed a binary locally for myself, then often that's because I found that the system version is too old or something -- I want the thing I just installed to be the thing that's found, overriding the system version. Really though either way would be much better than the current situation. The other question is where it should be added. The two obvious options are /etc/skel/.profile, and /etc/profile. Again, Fedora uses /etc/skel/.bash_profile, so I guess adding it to Debian's /etc/skel/.profile would make sense. (Debian has no /etc/skel/.bash_profile; Fedora has no /etc/skel/.profile; so I treat them as equivalent.) The advantage of adding it to /etc/profile would be that it would be added to existing installs, whereas adding it to /etc/skel/.profile would only affect newly created accounts (and thus take much longer to propagate out to the point where pip and friends start actually working). But again, either option would be much better than the current situation. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-rc7-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bash depends on: ii base-files 9.6 ii dash 0.5.8-2.2 ii debianutils 4.7 ii libc6 2.22-5 ii libncurses5 6.0+20160319-1 ii libtinfo5 6.0+20160319-1 Versions of packages bash recommends: ii bash-completion 1:2.1-4.2 Versions of packages bash suggests: pn bash-doc <none> -- no debconf information
