Pip: "standalone" install flag

Created on 21 Jan 2020  路  4Comments  路  Source: pypa/pip

What's the problem this feature will solve?

Many new users just want to install an end product, some cli tool or app, and end up polluting their user or global environment with a bunch of library packages, packages that are often incompatible with one another.

Describe the solution you'd like

I'd like to see a --standalone flag that install a piece of software in it's own virtualenv in the users home dir.

For example a user could run pip install --standalone docker-compose and instantly get a fresh install of docker-compose, in it's own virtualenv.

Alternative Solutions

I'm sure there are other ways to do this, but they don't have the same impact as there clearly being one obvious standard.

Additional context

All the same arguments that apply to static/shared libraries probably apply to this situation as well. Still, there are a lot of newcomers coming into the python scene and a command like this should help them not mess up their python env too much.

I presume something like this has been suggested before, but I can't find it.

needs discussion feature request

All 4 comments

Thank you for the suggestion!

pipx does exactly what you're describing. There is a lot of effort that goes into making a nice user experience, handling edge cases, writing tests, and writing documentation. pipx has done the work and is very easy to install and use. IMO it would be better to use that than to try to add this in pip.

Pipx looks great, I'll very likely use it from now on. Certainly simplifies a workflow I do pretty regularly. It seems like the kind of feature that might be worth having in core pip though, if only to introduce it as a standard.

The big issue is not that it's hard to do, it's that it's not very discoverable. It's not the default for people posting about their projects, even when it would really make more sense for it to be.

Not sure if it's something that makes sense for pip, but if it did that could see some more serious deployment. If it's compatible with pipx so you can use all of their fancy features, even better!

I can't really see someone starting their documentation with pip install xpip, and python is starting to get known for environment problems over longer term. I think a standalone install is a more sane default than what we mostly use now, but without someone setting it as the standard it's going to be hard for it to take off, it's always going to look "unofficial", like it's not the preferred way to do things.

I think we can mitigate the perception concerns by pointing people to the relevant packaging.python.org page that mentions pipx.

For info, you can kind of get halfway there with two commands like the following:

$ python3 -m pip install --target ./cookiecutter/ cookiecutter
$ python3 -m zipapp --python '/usr/bin/env python3' --main 'cookiecutter.__main__:main' ./cookiecutter/

This gets you a single file self-contained executable cookiecutter.pyz.

Lots of caveats, though, that's why solutions such as _shiv_, _pex_, and _pipx_ are better at this. But interesting nonetheless. See the zipapp documentation for details.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jeanlaroche picture jeanlaroche  路  89Comments

HenrikOssipoff picture HenrikOssipoff  路  94Comments

qwcode picture qwcode  路  89Comments

dstufft picture dstufft  路  170Comments

jaraco picture jaraco  路  99Comments