pipenv

Virtualenv was for me until 2020 a python-default tool for creating isolated virtual environments for python projects.
Virtualenv was always easy to handle and known as a mature pythonic tool under python developers.

But now, I think pipenv is stable and known enough to switch to it.

Motivation to switch to pipenv

• pipenv provide a better workflow than virtualenv
• application dependency management works better than in virtualenv
• ‘freezing’ of any installation of libraries and dependencies works automatically. This saves time and the chance to run into an deprecation issue with your code is near zero
• pipenv brings security for your projects

Installation

$ pip3 install pipenv

Use case

Create a project directory or switch to existing one.
Unlike virtualenv, the virtual environment can be created by running the installation of a new library:

$ cd ~/devel/my_project
$ pipenv install requests

Activate already existing virtualenv:

$ pipenv shell

Security checks

Checks the virtual environment for security vulnerabilities and against PEP 508 markers provided in Pipfile:

$ pipenv check

Virtualenv Backwards compatibility

Pipfile/Pipfile.lock are the modern requirements.txt or the replacement for it.
But this doesn’t mean, that all of your requirements.txt from earlier projects are worthless.

pipenv is with virtualenv compatible, that means, pipenv can generate requirements.txt and perform installations from requirements.txt files.
If any project member has not switched yet to pipenv, workflows can still be arranged with both tools.

Generate requirements.txt:

$ pipenv run pip freeze > requirements.txt

Install from requirements.txt:

$ pipenv install -r requirements.txt