Pip: `pip install` to automatically create virtualenv and install from requirements.txt

[metakermit]

Don't know if this was asked somewhere already, but wouldn't it be nice if doing a simple

pip install

would automatically install from _./requirements.txt_ and in case the command was refused due to missing sudo privileges (i.e. attempting to install into the system Python site-packages) automatically creates a _venv_ in the current directory (now that we have python -m venv in Python 3) and installs the packages in there. For beginners, this would literally allow installing just the Python 3 interpreter, getting the source code of an application and then installing the dependencies in one command, without having to know any virtualenv stuff in their first encounter with Python.

Having been involved in several beginner Python workshop events as a coach, I think something like this would be a pretty neat feature.

Similar behaviour that is available as npm install for Node apps seems pretty handy to me, when I just fetch some app source and have it ready for launching after issuing a single command.

What do you think?

[msabramo]

It sounds a bit too magical to me and trying to guess what the user intended. Maybe the user didn't want a virtualenv -- or if they did, for what version of Python and what would it be called?

pip install --user and pip install --require-virtualenv might be interesting for this use case.

And it was just discussed that we want to allow sudo pip install -- see https://github.com/pypa/pip/pull/2403

[metakermit]

Well, you know what Arthur Clarke says :)

Any sufficiently advanced technology is indistinguishable from magic.

Regarding the version, I'd say it should use whatever version of Python is driving the pip cli. The users who care about these details could still create virtualenv manually the normal way.

[Ivoz]

Equivalent to npm install for pip would be pip install .

[Glavin001]

+1! I was literally discussing my hopes for this potential feature in pip with @valencik.
I use npm and really appreciate being able to quickly and easily _reproduce_ the installation of an application by simplifying running npm install. The lack thereof in pip makes me a little uneasy, and so having something as simple and powerful (to quickly reproduce apps) as pip install would bring me great joy! I hope that this idea is accepted.

what version of Python and what would it be called?

I am not sure if this has been discussed before, however I was also hoping for something more detailed than requirements.txt file with a list of dependencies. Like package.json in Node.js development, it would be great to have a requirements.json file for Python packages and they would incorporate fields for supported Python versions, dev and normal dependencies.

pip install would evaluate this requirements.json (or requirements.yaml) and quickly be able to create a virtualenv with the correct version of Python and install all of the applicable dependencies.

My biggest complaint when developing Python applications is using pip and lack of simplicity and common workflow that creates a reproducible installation.

I had a lot of headaches when my dev team had upgraded their server from Python 2.7.x to Python 3.x and not being on the Python dev team I had some struggles. When I went to test it out, I spent quite some time learning about pip and virtualenv and how to select versions of Python for virtualenv creation, clearing out my previous virtualenv and then fixing some dependencies that had broken.
I just wanted to run one command, pip install, and have it make the virtualenv and select the correct Python, and install the dev and normal requirements.
A lot of my problems have been because of my lack of experience with Python and pip and I am definitely more comfortable now, however I still would be much more comfortable and willing to use Python for new projects / hackathons if I had some consistency and could _quickly and easily_ reproduce my projects installation.

I would be very interested in contributing and developing out this feature request, if there is interest. Before I develop anything, I would like to make sure that the pip / Python team discusses this through and we have a solid goal/plan on what we want to see. I would like to use Python more, however until I can have the simplicity and consistency of Node.js and npm I will continue to opt for Node.js projects at hackathon events and for personal / work projects until this and other such usability features are resolved.

Thank you!

---

Maybe the user didn't want a virtualenv

@msabramo why would a user not want a virtualenv? I am still new to Python and using pip and virtualenv, however since dependencies change between packages / projects and only one version is accessibly to and used by Python, would it not make sense to _always_ have separate virtualenv for projects? If you could clarify, I would appreciate it. I'd like to learn more about expected practices for Python development.

[Glavin001]

Could we use the pip config file to store whether or not the user desired this behaviour? See https://pip.pypa.io/en/stable/user_guide.html#config-file
Creating virtualenv automatically could be an opt-in feature. I know I would use it if I could type pip install and easily get a reproducible environment all working.

[msabramo]

Folks might be interested in http://platter.pocoo.org/dev/ as it creates a tarball with a bunch of wheels and a script that creates a virtualenv and installs the wheels.

[staticdev]

+1 for the idea of the convention name of the requirements file and installation when doing 'pip install'.
And also +1 for the default formatting of requirements for being .json (it is becoming industry standard).

[honzajavorek]

I think the configuration format should NOT be .json, since it doesn't allow comments. IMHO it's the largest downside of e.g. package.json for npm (which is, otherwise, awesome).

[lovato]

Hello all. Any new ideas on the last 2 years about this? I ended here only today, when searching for recommendations about req file and also dev-req file.

Basically, the way NPM handles this is PERFECT IMHO.

There can be:

• sections on requirements.txt
• pip it install ALL deps by default
• you can choose to not install development ones with a --production flag

So, my dream is:

• a single requirements file (convention to requirements.txt?) with sections for PROD and DEV purposes
• pip to work just by issuing "pip install" (line npm install)

This would allow all dependencies to be installed for development purposes, and for deployment (which is usually scripted) you just get rid of dev deps by a --production_only-like flag.

Any comments?

[pradyunsg]

This is something that the pipfile format is intended to bring: https://github.com/pypa/pipfile.

[pradyunsg]

Closing as a duplicate of #1795.

[metakermit]

@lovato yes, in a way Pipenv has solved this issue.

[bittner]

Virtual environment support is part of the Python standard library and "is now recommended for creating virtual environments" since Python 3.5. Interestingly, pip is still a separate tool that you have to manually ensure it is installed.

Let's pretend there are no Python versions around that still need to install virtualenv, then it should be natural to assume that making pip use the built-in feature of handling virtual environments is a good idea. Because it's an official citizen, not an experiment.

And while Pipenv does a good job for local development, it's still a separate tool you have to install unnecessarily just for deploying your dependencies, and it forces you to have a virtual environment (which is unnatural and cumbersome for, e.g., Docker-based deployments -- _opinions may vary_).

There really shouldn't be ranting about whether or why Pipenv is an officially recommended tool, but rather the essential features and workflows Pipenv is demonstrating should be integrated into pip itself. It shouldn't really be that difficult.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.