On 10 November 2015 at 09:24, Chris Barker <chris.bar...@noaa.gov> wrote: > As it happens, I am in the middle of a intro class that's using python3.4 or > 3.5 right now -- and I am telling everyone to do: > > python3 -m pip install > > Yes, plain old "pip install" is nicer, but only a little bit, and the > biggest reason we really, really want that to still work is that there are a > LOT of instructions all over the web telling people to do that -- so really > too bad if it doesn't work! But the reality is that it often DOESN'T work > now! and when it doesn't newbies really have no idea why in the heck not! > > personally, I think the best approach is to deprecate plain old "pip > install" -- if it's not there as an option, I expect no one will find it odd > that to install something for python, you might use python to do that!
Long thread, so I'm picking a semi-random spot to chime in, rather than replying to every part individually. I think there are a few different aspects worth considering here: 1. The ergonomics of "pip install X" are really nice, it's by far the most common instruction given in project documentation, and we're still in the process of updating documentation to recommend it over "easy_install X" (or sometimes even over running "./setup.py install" directly). We *want* it to be the right answer for installing Python packages, especially in single-installation scenarios. 2. There's one particular reason I *didn't* specify it as the default recommendation in https://docs.python.org/3/installing/: until Python 3.5, the "pip" executable wasn't placed on the PATH on Windows by default, even if you'd enabled PATH modification when installing Python (the problem is that the installers for Python 3.3 and 3.4 only add the directory where CPython itself resides to PATH, but not the Scripts directory where "pip.exe" ends up, while even earlier versions didn't offer the option to modify PATH automatically at all) So that meant "python -m pip" gave me the broadest coverage - it worked for everything except system level Python 3 installation on *nix systems. With the path issue being fixed in Python 3.5, we're now in the situation where "pip install X" based instructions will work in all of the following "single installation" scenarios: - any activated virtual environment (including conda ones) - Windows Python 3.5+ installations (with PATH modification selected at install time) - *nix Python 2 installations (including Mac OS X and Linux) "pip install X" still doesn't work for system Python 3 installations on *nix systems - you need "pip3 install X" or "python3 -m pip install X" there Windows Python 2 installations require manual PATH modifications regardless, but it's more common for people to know how to make "python -m pip install X" work, than it is for them to remember to also add the "Scripts" directory needed to make "pip install X" work. 3. I've started thinking of pip as a "plugin manager" for Python. This is mostly a consequence of work, since many of the challenges we face in dealing with language specific package management systems are akin to the ones we encounter with the plugin management systems in web browsers and IDEs like Eclipse. (It also helps to more clearly differentiate it from conda, which has the much broader role of being a data analysis environment manager) The problem with pip in its current form for that role is that it's installed as a standalone tool, but isn't natively multi-version aware. Accordingly, the ideas I like the most are the ones that suggest taking it down the path of the "py" launcher - make it natively multi-version aware, and have it choose a well-defined default target version if multiple versions are available. Longer term, it may even make sense to take the "python" command on *nix systems in that direction, or, at the very least, make "py" a cross-platform invocation technique: https://mail.python.org/pipermail/linux-sig/2015-October/000000.html Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig