Development environment

Handouts

This handout collects much relevant information about what to consider when setting up ones development environment, such as choice of editor and Python environment management. For first time Python users or beginner codes it is recommended to simply follow the tutorials linked below. For more experienced users, and later in this course, the below handout may serve as a starting point for upgrading your environment and how you interact with it.

Skill tree

First time Python user?

Code Refinery also has some great tutorials on setting up a starting environment, including installing and setting up git and github , editors such as VSCode and vim, and anaconda. Although for this course, I do not recommended anaconda for beginners as we aim to directly work with environments as a starting point and anaconda might be something you choose to use later on.

Code Refinery together with Aalto Scientific Computing also has some crash courses on using the shell, which is required for this course:

Python version lifetimes

It is easy to be tempted to just keep your system as it is and never update because its not broken right? Well, what this causes is a pileup of issues that need to be fixed all at once. At some point you will change computer, you will re-install, you will get a collaborator that keeps up to date, there will be some bug fixes you need. When that happens you will need to update. To keep the pain minimal, its better to take the pain a litle bit here and there, i.e. keep up to date!

A good way, besides running regular system updates and fixing issues as the emerge, is to keep track of python versions devguide. This lists which versions are currently being updated and maintained while which versions are nearing end of life and you should consider making sure your software and your environment is compatible with a newer version.

Don’t know which editor to choose?

What is a “Development environment”

A development environment is simply the set of programs and patterns that you use to

1. write code
2. run code
3. debug code
4. (deploy code)

As many of us who started programming as kids, my first “development environment” was notepad, cmd and the then new and cool mingw32.

In essenece you do not need a lot to have a development environment. Back then notepad let me edit the code, mingw32 and cmd.exe allowed me to compile and run it. Debugging occurred by reading compilation and runtime errors (bad as they were in those days) and by littering the code with “im here now!” print statements. Deploying was literally the same as running the code locally so I had that covered too.

Python environment

One of the most common pitfalls with Python is managing multiple projects with different dependencies across different versions, and maintaining these over time.

This is why there are a whole host of tools that have been developed to do this for you. A few popular alternatives are:

• venv
• pyenv
• uv
• anaconda
• miniconda
• poetry
• pipenv
• hatch
• pdm

In addition to these, many editors today have built in environment management. Some popular options are:

• spyder
• vscode
• vscodium
• pycharm

During this course I recommend choosing two things:

1. A system for downloading and compiling Python versions
2. A way to create Python virtual environments

If you already have a preferred way to work with Python, go with that and learn how to create and manage virtual environments. During the course I expect you to be able to create a new empty environment with whatever Python version we require.

If you are completely new to the whole environment thing I like to keep things simple: use Python’s built in venv command to create environments.

Using this command, you can create an environment with Python equal to the system Python version by running the venv command:

1

python -m venv /path/to/new/virtual/environment

The Python that runs the command dictates the version. Lets say you have python3.11 and python3.7 installed. You can then make two different virtual environments with two different version by

1
2

python3.11 -m venv env3.11
python3.7 -m venv env3.7

Then you can activate this environment as per the documentation.

Once you have a Python environment created with venv you can install packages into this environment using pip. pip by default looks for packages on the central Python repository called PyPI. Which means that running

1

pip install numpy

will fetch and install this package into the virtual environment. You can inspect what was installed by looking into <venv>/lib/python3.13/site-packages. If provided with a local path pip will also install from a locally available package source. You can even directly install from a version control repository, such as git, by using the pip VCS format.

To manage Python versions, I recommend using uv (or pyenv if you cant get uv to work) to download and manage Python versions. This tool is easy and stores the binaries locally in your home folder. This way you are not contaminating anything else and can easily just delete all the data if you want to start over. For example on my main machine I have:

1
2
3
4
5
6

danielk@IRF033-danielk ~> ls -l .local/share/uv/python/
Permissions Size User    Date Modified Name
drwxr-xr-x     - danielk 3 mar 16.29  📁 cpython-3.10.16-linux-x86_64-gnu/
drwxr-xr-x     - danielk 3 mar 17.17  📁 cpython-3.13.2-linux-x86_64-gnu/
drwxr-xr-x     - danielk 3 mar 17.03  📁 cpython-3.7.9-linux-x86_64-gnu/
drwxr-xr-x     - danielk 3 mar 17.03  📁 cpython-3.9.21-linux-x86_64-gnu/

While it is not strictly required during the course to have a way to install different Python versions, depending on the group-work problems might arise if you cannot internally settle on a single version.

Another option for running different Python versions is by using containers. This can be done using docker or podman. Here I would recommend podman as it is the open source alternative.

For example to run a Python 3.12 container I can do the following to download

1
2

danielk@IRF033-danielk ~> podman pull python:3.12
Trying to pull docker.io/library/python:3.12...

and run it:

1
2
3
4
5
6
7
8

danielk@IRF033-danielk ~> podman run -ti python:3.12 /bin/bash
root@e75f5e9469bf:/# python --version
Python 3.12.9
root@e75f5e9469bf:/# python
Python 3.12.9 (main, Feb 25 2025, 05:22:35) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pathlib
>>> 

There are many good tutorials on how to work with containers when developing code, e.g. this docker blog-post.

Working with venv

As it is really annoying to type source /really/long/path/to/activate.fish all the time it is recommended to remove some of that friction by creating a few shell-scripts or aliases.

It can be as simple as putting the following function in your .bashrc

1
2
3

activate() {
    source "$HOME/venvs/$1/bin/activate"
}

which assumes that all your environments are stored under $HOME/venvs/. Then you can simply type activate that-project.

The below snippets of bash and fish shell scripts are the ones I personally use together with pyenv to provide the following functions:

• lazyvenv
• activate
• venv
• venvdel
• venvs

These create new environments in $HOME/venvs/ with venv and can delete them with venvdel. But my favorite command is lazyvenv which just looks at the name of the current folder and tries to activate a virtual environment with that name, and if it cant find one it creates it.

This is very similar to how uv works if one lets it manage all aspects of your virtual environment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

function user_confirm
    while true
        set -l prompt "$argv [y/N] "
        read -l -P $prompt confirm

        switch $confirm
        case Y y
            return 0
        case '' N n
            return 1
        end
    end
end

function venvdel
    set -l path "$HOME/venvs/$argv"
    if user_confirm "Do you want to delete '$path'?"
        echo "removing '$path' ...."
        rm -rfv "$path"
    end
end

function activate
    source ~/venvs/$argv/bin/activate.fish
end

function lazyvenv
    set -l name (basename (pwd))
    if test -d ~/venvs/$name
        activate $name
    else
        echo "No venv found: creating venv"
        venv
        if test -d ~/venvs/$name
            activate $name
        end
    end
end


function venv
    if test (count $argv) -eq 0
        set venv_target (basename (pwd))
    else
        set venv_target $argv[1]
    end
    if test (count $argv) -ge 3
        set extra_args $argv[3..(count $argv)]
    else
        set extra_args ""
    end

    if not test -d ~/venvs
        mkdir ~/venvs
    end
    echo "New venv target=$venv_target" 

    if test -d ~/venvs/$venv_target
        echo "Folder '~/venvs/$venv_target' exists, choose a different name for new venv"
        return 1
    else
        if type -q uv
            if test (count $argv) -eq 2
                uv venv --seed --python $argv[2] $extra_args ~/venvs/$venv_target
            else
                uv venv --seed ~/venvs/$venv_target
            end
        else
            if test (count $argv) -eq 2
                echo "Cant use specific python version without uv"
                return 1
            end
            python -m venv ~/venvs/$venv_target
        end
        echo "Created virtual enviornment $venv_target"
    end
end

function venvs
    for dr in ~/venvs/*
        echo (string split / $dr)[-1] "| python" (cat $dr/pyvenv.cfg | grep version)
    end
end

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

# user_confirm function
user_confirm() {
    local prompt="$1 [y/N] "
    while true; do
        read -p "$prompt" confirm
        case "$confirm" in
            Y|y) return 0 ;;
            ''|N|n) return 1 ;;
        esac
    done
}

# venvdel function
venvdel() {
    local venvpath="$HOME/venvs/$1"
    if user_confirm "Do you want to delete '$venvpath'?"; then
        echo "Removing '$venvpath' ...."
        rm -rfv "$venvpath"
    fi
}

# activate function
activate() {
    source "$HOME/venvs/$1/bin/activate"
}

# lazyvenv function
lazyvenv() {
    local name
    name=$(basename "$(pwd)")
    if [[ -d "$HOME/venvs/$name" ]]; then
        activate "$name"
    else
        echo "No venv found: creating venv"
        venv
        if [[ -d "$HOME/venvs/$name" ]]; then
            activate "$name"
        fi
    fi
}

# venv function
venv() {
    if [[ $# -eq 0 ]]; then
        venv_target=$(basename "$(pwd)")
    else
        venv_target="$1"
    fi

    if [[ $# -ge 3 ]]; then
        extra_args="${@:3}"
    else
        extra_args=""
    fi

    if [ ! -d "$HOME/venvs" ]; then
        mkdir "$HOME/venvs"
    fi
    echo "New venv target=$venv_target"

    if [[ -d "$HOME/venvs/$venv_target" ]]; then
        echo "Folder '~/venvs/$venv_target' exists, choose a different name for new venv"
        return 1
    else
        if command -v uv &> /dev/null; then
            if [[ $# -eq 2 ]]; then
                uv venv --seed --python "$2" $extra_args "~/venvs/$venv_target"
            else
                uv venv --seed "~/venvs/$venv_target"
            fi
        else
            if [[ $# -eq 2 ]]; then
                echo "Can't use specific python version without uv"
                return 1
            fi
            python -m venv "~/venvs/$venv_target"
        fi
        echo "Created virtual environment $venv_target"
    fi
}

# venvs function
venvs() {
    for dr in "$HOME/venvs"/*; do
        echo "$(basename ${dr}) | python $(grep version ${dr}/pyvenv.cfg)"
    done
}

However, if you choose to e.g. use uv completely you will never even activate your environment: uv will manage that for you. Similarly with many other environment managers you do not directly interact with the environment.

Editor

We already mentioned some popular editors that have a lot of functionality baked into them and are often called Integrated Development Environments (IDEs). However, most of this course will not focus on making us experts at using IDEs but making us experts at software development. For that we simply need to write and edit code efficiently.

A few popular editors are:

• vim
• nvim
• emacs
• sublime text
• kate
• geany
• spyder
• vscode
• vscodium
• pycharm
• notepad++

At minimum I recommend having an editor that has the following features:

• Syntax highlighting
• Language Server Protocol (LSP) integration or some sort of symbol finding system ( e.g. ctags )
• Text searching and go-to functionality
• File-browsing or file-searching

Having these features will make life a lot simpler and speed up development by quite a lot.

Personally - I use VSCode and nvim. I mostly still have VSCode until I fully learn how to use vim-motions efficiently. In my journey I have went trough pretty much the entire list of editors and IDEs above, I started out simple, sought out complexity, and now I’m back inside a terminal just coding again.

A pretty cool interactive vim tutorial is available on openvim.

Homework assignments

Install git

If git is not installed on your system (try git --version), install it (remember to always favor your package manager) and create a new repository for homework solutions.

If you want - upload the repo on codeberg, github, or gitlab.

Virtual environments

Choose a method to manage virtual environments and implement it, write a cheat sheet for creating, entering, exiting and deleting environments.

Editor mastery

Go trough the shortcuts that your chosen editors has, create a short cheat sheet for the shortcuts that you think are the most useful!

Some suggestions are “Goto definition”, “Fuzzy find [file/symbol]”, “Goto line”, “Goto symbol”