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
$ pip3 install pipenv
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
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.
$ pipenv run pip freeze > requirements.txt
Install from requirements.txt:
$ pipenv install -r requirements.txt