I will admit to not being a huge fan of python and also admit to not being entirely sure why. I have in the past spent a reasonable amount of time learning the language (2.7 days) and it seem ideal for certain type of coding I want to do.

So in an attempt to dispel or re-affirm my bias I am giving python another go. As this is a start of, perhaps, a new friendship I wanted to spend a few hours at the start learning some of the tooling. Not the IDE side of things, I will use either CLion or emacs. Rather pip, virtualenv and pyenv.

#### Pip

Pip, or more likely pip3 if you are on Ubuntu, is the package manager for python modules. I imagine every programmer has typed pip3 install pygame or similar to install a package. It does not attempt to satisfy the native libraries needed to run your package. That is when you install pygame you are on your own making sure the SDL2 requirement is forfilled - at least that’s how I understand it.

By default pip will install a package and make it globally available. This is awkward if you need two different versions for two different applications. The next couple of tools help you solve that.

One nice feature that I had not played with in the past is you can type pip3 freeze and it will print a list of your requirements. Pipe this to a text file (usually requirements.txt) and commit it to your version control. This allows you to install all your requirements using just a single command, pip3 install -r requiriments.txt. Which is pretty cool. Obviously this is meant to be used in conjunction with virtualenv which we are just about to get to.

#### Virtualenv.

Virtualenv lets you create a virtual environment for python to run in. This means it creates an enviroment where no packages are installed by default. When you install a package it will be on available to your project. This allows fine control on what is available to your project and provides stability to your system by not installing weird version of things other parts of you system might be dependent on. Virtualenv probably has a ton of other features but they don’t seem relevant to a simple dev enviroment I want.

I am very new to this but I don’t think I will actually use much of the Virtualenv tooling directly instead I think I will use it via pyenv.

The key takeway is virtualenv along with requirments.txt lets you set up a consistent development environment. Well nearly…

#### Pyenv.

Pyenv fills the final gap of letting you specify the version of python you want to use. It also provides an interface to using virtualenv that I plan to use. This is covered, along with installation, here. For me the important details are to create an enviroment you use pyenv virtualenv 3.9.0 myenvname where 3.9.0 is the version of python to use.

From a shell inside your project directory you run

pyenv local myenvname


This creates a .python_version file containing the name of the environment to use. If you have set up pyenv correctly including the additions to your .bashrc file then when you enter that directory the enviroment will automatically be used. You can check this with pyenv which pip3.

#### Summary

So it seems the key to the work flow is:

• Use virtualenv to isolate yourself.
• Use pip3 to install/freeze the requirements and easily install them
• Use pyenv to choose the version of python you want to use and automatically set up environment.

Personally I had seen these tools in use but never really taken the time to understand them. If I am being honest I I assumed it was an complication I didn’t need as I was hacking away are simple scripts. I could not be more wrong! Using pyenv should have been my default for pretty much everything - lesson learned.

This bodes reasonably well for my return to python. The plan is to use python for some of the more learning based projects I have planned. Outside of deployment to servers I appreciate writing python to be used anyone else is problematic so I don’t think it will become my go to language for things I actually want to show people.

722 Words

2020-11-15 00:00 +0000