alias pip="python -m pip"
python -m pip instead of
pip ensures you are using the version of
pip for your local python. I've definitely had times where using it instead of just
pip fixed issues for me.
The second is:
alias newenv="python3.11 -m venv --prompt . .venv && .venv/bin/pip install -U pip setuptools wheel"
This isn't recommended as an alias in the book, but the pattern is recommended. I set this up as an alias because I've been playing around with a few small projects lately, which has caused me to create and recreate environments repeatedly. This makes it much simpler. The big win for me here is that I really don't like another recommended pattern I see in other places which is
python3.11 -m venv venv. The problem with this is that your prompt always looks like:
How do you know which environment is active? I rarely have issues related to this since I usually use separate terminals for separate projects, but it provides me peace of mind to know I'm in the correct environment. This brings me to my third new alias:
alias act="source .venv/bin/activate"
Again, I just got tired of typing all of that. And by using --prompt in the previous alias, I can have my prompt match the project while the virtual environment folder name is consistent across all projects. This allows me to run
act in any folder where I have a virtual environment and activate it!
In addition to adding these to my development desktop, I also created a dotfiles repo. Now, whenever I set up a new machine (or use my laptop for travel), I can have the same aliases everywhere. Here are two great examples of dotfiles repos: Ned Batchelder and Matt Layman.
Finally, another tip regarding
pip tip, if you will: Set up
pip to require an active virtual environment. There are several ways to do this, mentioned in this blog post. If you want to save a click, execute
pip config set global.require-virtualenv True. It will set the config file for you automatically. If you want to read more, click through.
The common use case this prevents is accidentally installing a bunch of packages (usually with
pip install -r requirements.txt) to your global
pip. However, I just ran into another nice use case for this today. I had moved a virtual environment from a subfolder to the main folder of a project (I was experimenting with different ways to create the project so I had a few projects in a single repo). When I tried to use the environment again,
pip told me there was no virtual environment active even though I had activated it. I'm not exactly sure what caused the issue, but I wouldn't be surprised if it would have caused more issues down the line. Instead, I just deleted the virtual environment, remade and activated it with my handy new aliases!