[Python-ideas] High time for a builtin function to manage packages (simply)?
Andrew Barnert
abarnert at yahoo.com
Wed Sep 9 23:18:06 CEST 2015
On Sep 9, 2015, at 01:56, Paul Moore <p.f.moore at gmail.com> wrote:
>
> Apart from that issue, which is Windows only (and thus some people
> find it less compelling) we have also had reported issues of people
> running pip, and it installs things into the "wrong" Python
> installation. This is typically because of PATH configuration issues,
> where "pip" is being found via one PATH element, but "python" is found
> via a different one. I don't have specifics to hand, so I can't
> clarify *how* people have managed to construct such breakage, but I
> can state that it happens, and the relevant people are usually very
> confused by the results.
If StackOverflow/SU/TD questions are any indication, a disproportionate number of these people are Mac users using Python 2.7, who have installed a second Python 2.7 (or, in some cases, two of them) alongside Apple's. Many teachers, blog posts, instructions for scientific packages, etc. recommend this, but often don't give enough information for a novice to get it right.
Many people don't even realize they already have a Python 2.7; others are making their first foray into serious terminal usage and don't think about PATH issues; others are following old instructions written for OS X 10.5 that don't do the right thing in 10.6, much less 10.10; etc. And even experienced *nix types who aren't Mac experts may not realize the implications of LaunchServices not being launched by the shell (so anything you double-click, schedule, run as a service, etc. won't see your export PATH that you think should be solving things). Even Mac experts are thrown by the fact that Apple's pre-installed Python is in /usr but has a scripts directory in /usr/local, so if you install pip for both Apple's Python and a second one, whichever one goes second is likely to overwrite the first (but that isn't as common as just having /usr/bin ahead of /usr/local/bin on the PATH--because Apple's Python doesn't come with pip, this is enough to have your highest pip and python executables out of sync).
Whenever someone has a PATH question, I always start by asking them if they're on a Mac, and using Python 2.7, and, if so, which if any Python installs they've done, and why they can't use virtual environments and/or upgrade to Python 3.x and/or use the system Python. The vast majority say yes, yes, [python.org|Homebrew|the one linked from this blog post|I don't remember], what's a virtual environment, my [book|teacher|friend] says 2.7 is the best version, this blog post says [Apple doesn't include Python|Apple's Python is 2.7.1 and broken|etc.].
As both Python 3 and virtual environments become more common (at least as long as Apple isn't shipping Python 3 or virtualenv for their 2.7), the problem seems to be becoming less common, but it's still depressing how many people are still writing blog posts and SO answers and so on that tell people "you need to install the latest version of Python, 2.7, because your computer doesn't come with it" and then proceed to give instructions that will lead to a screwed up PATH and make no mention of virtualenv...
More information about the Python-ideas
mailing list