[Python-ideas] High time for a builtin function to manage packages (simply)?

Nick Coghlan ncoghlan at gmail.com
Thu Sep 10 17:55:07 CEST 2015

On 9 September 2015 at 17:33, Ben Finney <ben+python at benfinney.id.au> wrote:
> Paul Moore <p.f.moore at gmail.com> writes:
>> On 5 September 2015 at 09:30, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > Unfortunately, I've yet to convince the rest of PyPA (let alone the
>> > community at large) that telling people to call "pip" directly is *bad
>> > advice* (as it breaks in too many cases that beginners are going to
>> > encounter), so it would be helpful if folks helping beginners on
>> > python-list and python-tutor could provide feedback supporting that
>> > perspective by filing an issue against
>> > https://github.com/pypa/python-packaging-user-guide
>> I would love to see "python -m pip" (or where the launcher is
>> appropriate, the shorter "py -m pip") be the canonical invocation used
>> in all documentation, discussion and advice on running pip.
> Contrariwise, I would like to see ‘pip’ become the canonical invocation
> used in all documentation, discussion, and advice; and if there are any
> technical barriers to that least-surprising method, to see those
> barriers addressed and removed.

We're doing that too, but it's a "teaching people to use the command
line for the first time is hard" problem and a "managing multiple
copies of a language runtime and ensuring independently named commands
are working against the right target environment" issue, moreso than a
language level one.

A potentially more fruitful path is likely to be making it so that
folks don't need to use the system shell at all, and can just work
entirely from the Python REPL.

The two main things folks can't do from the REPL at the moment are:

* install packages
* manage virtual environments

The idea of an "install()" command injected into the builtins from
site.py would cover the first.

The second couldn't be handled the way virtualenv does things, but it
*could* be handled through a tool like vex which creates new subshells
and runs commands in those rather than altering the current shell:

$ python3
Python 3.4.2 (default, Jul  9 2015, 17:24:30)
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.call(["vex", "nikola", "python"])
Python 2.7.10 (default, Jul  5 2015, 14:15:43)
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print("Hello virtual environment!")
Hello virtual environment!

The "vex nikola python" call there:

1. Starts a new bash subshell
2. Activates my "nikola" virtual environment in that subshell
3. Launches Python within that venv (hence the jump over to a Python
2.7 process, since I keep forgetting to recreate it as Python 3).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list