My Python workflow is constantly changing as new tools emerge to make things faster and easier. In this post, I want to share my current workflow as of November 2020.
brew install pyenv
pyenv is installed, you can run the bare command and list all of the options.
The main two are
pyenv install and
I start out on a new machine with the following:
pyenv install 3.8.5 which is only needed once to install the version.
Then I run
pyenv global 3.8.5 which sets the global python default as
To view all installed versions, you do
pyenv versions like so:
$ pyenv versions system 3.6.8 3.7.7 3.7.8 3.8.1 3.8.2 * 3.8.5 (set by /Users/jamescampbell/.pyenv/version) 3.9.0b5
Using Pyenv Local
For any new project in my projects folder:
pyenv local 3.8.5which creates a new dot file
The answer is to handle it per project and with pipenv.
Full Documentation of Pyenv.
Pipenv is a virtual environment and package manager all in one. It was created by Ken Reitz, the guy who is famous for Requests, so you know it is top quality and makes sense.
pip install pipenv for the project and pyenv version of Python you are working on.
How To Use Pipenv
pipenv install to replace the bare
pip command to install all packages. This creates a lockfile,
Piplock and keeps it up to date along with a
To use the environment, it is very similar to
venv, you execute
pipenv shell which will activate your virtual environment that has everything installed and locked in. When you are done you simply run
exit to get out of the virtual environment.
As an alternative to the
pipenv install for individual packages, you can also point it to a requirements.txt file via
pipenv install -r /path/to/requirements.txt.
Common Use Case
I will step you through a common use case:
- Create a new project folder
- Change directory into the folder
pyenv local 3.8.5or whatever version you want to use
pipenv install requests, beautifulsoup4or whatever packages you need
- Write your python code and iterate from there using version control, etc. like normal
- When you are done, exit the virtual environment via
As you can see, the ultra-combo of having python version control locked down for my global as well as my local project environment as well as having package versioning at the project level along with a virtual environment specific project saves me tons of time and just works.
Having a Pipfile and a requirements.txt file at the root of my project along with the
.python-version dotfile ensures that all of my Python code stays organizes and is guaranteed to work and be repeatable and explorable by others.