Since my last post on aliases, I've added a few new aliases. Two are from Boost Your Django DX, which I'd highly recommend. The first is a straight cut from the book:

alias pip="python -m pip"

Using 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:

(venv)computername:~/home

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. A 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!