Dan's Blog

Why I'm Betting on uv: The Python Package Manager I Wish Existed Years Ago

Mon, 28 Jul 2025 07:22:00 +0100

I started my career working with Java, where tools like Maven made managing dependencies simple and reliable. Everything just worked (more or less). You didn’t have to worry about setting up different tools or whether your project would build the same way every time.

When I started using Python, things weren’t quite as smooth. Python is powerful and flexible, but managing environments and dependencies always felt messy compared to Java and Maven. I often wished for something more predictable and organised.

That’s why uv caught my eye. It’s not entirely new, it’s been around for a while, but it’s really starting to mature. uv brings together everything needed for Python project management into one modern, fast tool. Here’s why I think it’s worth serious consideration.

What is uv and why should you care?

uv is designed to replace pip, pip-tools, and virtualenv with a single command-line tool. If you’ve ever thought Python’s packaging story felt clunky compared to Node’s npm or yarn, uv is what you’ve been waiting for.

You can install it on macOS with:

brew install uv

or follow other installation instructions from the uv GitHub page.

If you’ve used Node.js before, uv will feel familiar, it’s like npm for Python - dependency management, environment isolation, and builds in one.

Quick start and how I got going

The biggest compliment I can give uv is that it just works. Here are a few examples of how I got started:

# Download and manage multiple Python versions
uv python install 3.12 3.13 3.14

# Pin a global default Python version
uv python pin --global 3.14

# See where Python versions are stored
uv python dir

# Create a virtual environment in the project folder
uv venv .venv

# Run Python inside the environment (no manual activation)
uv run python --version

# Bootstrap a new app quickly
uv init --app --name my-app \
  --python 3.14 --managed-python \
  --no-readme --vcs none

uv keeps things tidy. You can use different Python versions in different projects, and switching between them is easy.

My initial observations

What I liked

Speed, installing dependencies and syncing environments is much faster than pip and virtualenv.
One tool for all tasks, no juggling between pip, pip-tools, and virtualenv.
Modern by default, everything is pyproject.toml-based.
Built-in Python management, like pyenv, but integrated.

What could improve

There’s still no single command to bump all dependencies to their latest versions (like yarn upgrade). For now, you have to update version numbers manually.

Should you switch to uv?

If you want a fast, simple, and unified Python development workflow, uv is a great choice. It’s already production-ready and has an active community of maintainers and contributors.

If you rely heavily on advanced Poetry-style features, it’s worth testing first. But uv feels like the direction Python tooling is heading. For my projects, the switch has already paid off.

My everyday usage flow

I now use uv daily and settled into a repeatable flow that keeps things clean and reproducible.

# Start fresh, remove old environment and lock files
rm -rf .venv uv.lock requirements.txt

# Sync dependencies based on pyproject.toml (creates a new .venv and uv.lock)
uv sync

# Inspect dependency tree
uv tree

# Keep .toml and .txt files in sync if you need the legacy requirements files
uv pip compile pyproject.toml --output-file requirements.txt

# Run a script directly
uv run python ./path/to/script.py

# Run tests with dev dependencies
uv sync --extra dev
uv run pytest

# In Visual Studio Code go to:
# Command Palette (⇧⌘P) → "Python: Select Interpreter"
# and choose `./.venv/bin/python` located in your project

A minimal working pyproject.toml example:

[project]
name = "my-app"
version = "0.1.0"
description = "Add your description here"
requires-python = ">=3.14"
dependencies = ["loguru>=0.7.3"]

[dependency-groups]
dev = ["pytest"]

This setup, one clear pyproject.toml and a consistent uv flow, has made my Python work much smoother. I no longer worry about drifting environments or mismatched dependencies.

Working with multi-package projects in `uv`

As my projects grow, I split them into separate components such as core, api, and cli. This is where I discovered one of uv’s best features, workspaces!

Workspaces let you manage several packages inside a single repository, with one lockfile, shared tooling, and clear internal dependencies. Here’s how I’ve been using them.

1. Create a top-level workspace

At the repository root, define a workspace in your pyproject.toml:

[tool.uv.workspace]
members = ["core", "cli", "api"]

Each folder (core, cli, api) will have its own pyproject.toml, but they’ll share one virtual environment and one uv.lock. This keeps the setup unified and avoids dependency duplication.

You can initialise these packages easily:

uv init core
uv init cli
uv init api

Then create the rest of the folder structure:

mkdir -p \
  core/src/core core/tests \
  cli/src/cli cli/tests \
  api/src/api api/tests
touch core/src/core/__init__.py core/tests/test_core.py
touch cli/src/cli/__init__.py cli/tests/test_cli.py
touch api/src/api/__init__.py api/tests/test_api.py

2. Link internal dependencies explicitly

If one package depends on another, for example, cli uses functions from core tell uv to link them locally at the top-level pyproject.toml:

[tool.uv.sources]
core = { workspace = true }

This tells uv to use your workspace version of core instead of fetching it from PyPI. Without this mapping, uv would assume core is an external dependency and try to install it from the registry.

3. Keep configuration DRY (Don’t Repeat Yourself)

For shared tools such as pytest, ruff, mypy, and black, define them only once in the root pyproject.toml:

[dependency-groups]
dev = ["pytest", "ruff", "black", "mypy"]

[tool.pytest.ini_options]
testpaths = ["core/tests", "cli/tests", "api/tests", "tests"]
addopts = "-ra -q"

This setup keeps your test and lint configuration consistent across all packages. Each sub-package automatically uses these tools when you run uv sync --extra dev. Keep in mind that uv commands, especially uv sync and uv run, should be executed from the root workspace directory, not from within an individual package. That’s how uv resolves shared dependencies and applies your top-level configuration correctly.

4. Handle imports cleanly in `src/` layouts

If you’re following the src/ layout (e.g. core/src/core), Python needs to know where to find those modules. You can fix this by adding to the root pytest config:

[tool.pytest.ini_options]
pythonpath = ["core/src", "api/src", "cli/src"]

This makes imports like from core import something work during test discovery.

5. Versioning without duplication

You don’t need to define __version__ manually in every package. Instead, read it directly from your project metadata:

from importlib.metadata import version, PackageNotFoundError

try:
    __version__ = version(__name__)
except PackageNotFoundError:
    __version__ = "0.0.0"

This small snippet keeps the version in sync with your pyproject.toml automatically. It’s one of those “set it once and forget it” improvements that make the workspace cleaner.

6. Organise integration and cross-package tests at the root

Place integration tests that touch multiple packages in a shared folder at the repository root:

tests/
├── test_integration_api_core.py
└── test_integration_cli_core.py

Since your root pytest config already points to all test folders, running tests from the top-level works out of the box:

uv run pytest

This makes it easy to test your system as a whole without leaving the workspace root.

Effective project structure

The layout below shows a clean, maintainable multi-package setup using uv workspaces. This pattern scales well for modular back-end systems, internal libraries, and CLI utilities that need to evolve together but remain logically separate.

.
├── api/                             # package: API
│   ├── src/api/
│   │   └── __init__.py              # API package root
│   ├── tests/
│   │   └── test_api.py              # unit tests for API
│   └── pyproject.toml               # package-level metadata
│
├── cli/                             # package: CLI
│   ├── src/cli/
│   │   └── __init__.py              # CLI package root
│   ├── tests/
│   │   └── test_cli.py              # unit tests for CLI
│   └── pyproject.toml               # package-level metadata
│
├── core/                            # package: Core business logic
│   ├── src/core/
│   │   └── __init__.py              # Core package root
│   ├── tests/
│   │   └── test_core.py             # unit tests for Core
│   └── pyproject.toml               # package-level metadata
│
├── tests/                           # root-level integration tests
│   ├── test_integration_api_core.py # cross-package integration test
│   └── test_integration_cli_core.py # cross-package integration test
│
├── .env.default                     # example environment variables
├── .gitignore                       # git ignore rules
├── .python-version                  # pinned Python version
├── Makefile                         # developer & CI/CD shortcuts (build, test, clean, etc.)
├── pyproject.toml                   # workspace root config (defines uv workspace)
└── README.md                        # project overview and documentation

Final takeaway

uv’s workspace model has become one of its most powerful (and underrated) features. It keeps multi-package repositories clean, removes duplication, and makes local development feel seamless.

For me, it’s the first time Python tooling has felt coherent across a full stack of packages, the kind of “batteries included” experience I wish we’d always had.

A Revised Way of Generating SSH Keys

Sat, 02 Sep 2017 22:16:00 +0100

I’ve been using 4096-bit RSA SSH keys for quite a few years. The RSA keys are very compatible. They’ve been working on various operating systems as well as on mobile devices. They are also known as being slow and potentially insecure if created with a small amount of bits, especially after the year 2013. Today, I decided to do some research to find an alternative configuration. Things have moved on since my last check. Large keys are still considered secure, however the elliptic curve cryptography has become much more popular in the recent decade.

“The primary benefit promised by elliptic curve cryptography is a smaller key size, reducing storage and transmission requirements, i.e. that an elliptic curve group could provide the same level of security afforded by an RSA-based system with a large modulus and correspondingly larger key: for example, a 256-bit elliptic curve public key should provide comparable security to a 3072-bit RSA public key.”

My take on it is that if this new signature algorithm can give us similar or even better level of security (yes, its implementation is more secure than RSA) with a comparable flexibility using less resources, it is definitely time to adopt it. For anyone who is interested in a detailed explanation how exactly it works a lot of papers have been published providing mathematical rationale behind it.

Ed25519 is a digital signature scheme based on Twisted Edwards curves. Its has been added to the OpenSSH codebase on the 7th of December 2013. Since then no issue was reported against it.

The easies way to generate such an SSH key is by using the ssh-keygen command of the OpenSSH package:

ssh-keygen -t ed25519 -o -a 100

The -t ed25519 parameter is used to generate two asymmetrical keys based on the elliptic curve cryptography. The output is produced in the new RFC4716 format rather than the well known PEM and the flag -o to support it is implied by default so it can be omitted. It enforces use of a modern key derivation function (KDF) powered by combination of PBKDF2 and bcrypt. In practice this means that our keypair is more resistant to brute-force password cracking. This is especially true when combined with the -a <rounds> parameter which specifies the number of key derivation function rounds to be used. Higher the number more time it takes to unlock the key.

Time to see the result of the above command. Here is an example of my revised way of generating SSH keys along with content of the files.

$ ssh-keygen -t ed25519 -a 100 -C "my-key-comment" -f my-key-name
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in my-key-name.
Your public key has been saved in my-key-name.pub.
The key fingerprint is:
SHA256:GIh0NDZ6WhZLyFJxq8dpbJ7aAwfEpJdgBsgxs/5NziM my-key-comment
The key's randomart image is:
+--[ED25519 256]--+
|*@*+X            |
|==OO B           |
|.+= B .          |
|...O . o         |
| .o.B.. S        |
|  o=*.           |
|   Eo=           |
|   oo .          |
|  . ..           |
+----[SHA256]-----+
$ puttygen my-key-name -C "my-key-comment" -o my-key-name.ppk
Enter passphrase to load key:
$ ls -la my-key-name*
-rw-------  1 dan  staff  464  3 Sep 21:27 my-key-name
-rw-------  1 dan  staff  304  3 Sep 21:27 my-key-name.ppk
-rw-r--r--  1 dan  staff   96  3 Sep 21:27 my-key-name.pub
$ cat my-key-name
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABA+HlsP7o
3Jzj8b+N+WhbEuAAAAZAAAAAEAAAAzAAAAC3NzaC1lZDI1NTE5AAAAIErbaYC9ZHLEtCY3
uDDl0LqRwlxLSGoHO1IBrvhzikyVAAAAoD632B3FjYbZmkLco+r7BVIvK3r1Cn2dJE8Q4N
l9IES8bieUYPxDi3uu3gaIcWwygdHTM5zFMqWePJgNP2M0jvfLkQLbaJd816D/BYwUGcTR
3Mgo7Rnf1qqoen70rwl67bbTaN8D0M5dNL5EkYdKvOoiRhoyQEIdptNOWF6rjwMyfloWw9
JMKCOfYrSUB4pDf6mgbWw7+60IUrIc+BeAQgc=
-----END OPENSSH PRIVATE KEY-----
$ cat my-key-name.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIErbaYC9ZHLEtCY3uDDl0LqRwlxLSGoHO1IBrvhzikyV my-key-comment
$ cat my-key-name.ppk
PuTTY-User-Key-File-2: ssh-ed25519
Encryption: aes256-cbc
Comment: my-key-comment
Public-Lines: 2
AAAAC3NzaC1lZDI1NTE5AAAAIErbaYC9ZHLEtCY3uDDl0LqRwlxLSGoHO1IBrvhz
ikyV
Private-Lines: 1
63bsFlto1i20tXwFu3xveXsGtDD7hEmsM0FrIGqviHn4O2xXG9Pwjmhmwf+z8rJe
Private-MAC: 72102d9a0f158f653577df276fcf329b482df329

Create Consistent SSH User Accounts Across Multiple Linux Servers

Tue, 22 Aug 2017 22:29:00 +0100

Due to a specific design requirements on a project I’ve been working on recently I needed to create a consistent system account on all the Linux servers across all the environments. This account supposed to have the following characteristics:

Same GID and UID
Both password and public SSH key are set
Only the SSH key-based authentication is allowed
Privileged operations are executed without having to provide password (optional)

As you can tell this is an admin type account that is usually created just after the installation of an operating system.

Servers are up and running. Setting it up by hand could be an option. However, this would be a very old-fashioned approach though. I already have an automation tool in place. My favorite one is Ansible due to its simple architecture. Whether or not our configuration management framework is really advanced and facilitates tweaking of every aspect of an OS or a VM in my opinion the best language to script it is Bash. The change will be expressed in a most readable way that every sysadmin or platform engineer as they are called these days will understand. I’m going to use Ansible only as an orchestration tool to ship the script across and execute it without any user interaction.

Here is our sample input:

id=1000
username="dan"
password="s3cr3t"
ssh_pk="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGA++RFH4MfQ+697dSNS+p2Hx0a4X56pnDrMIbDozYUPcbY6rictsJvsakaF2yMlR9xW0nEWichdwB5dFxoVQ9E6n6ygRB5Q88j+SOsvVA+wjCJ0+Ittfrb9/dTrnuSWT58p1HKaCDOJdx402P41DZGw4Fq+JKTEvP+H0AbOdUifNMrZBPZ0kOv/0bNT839ytI6rKGi+3w42TN37k7H02TmAFPnip3YpLrUMNxMHulxyzaQ2ueAILGmPac2pz6hU6OflSCkptiV7yDYv/LnjFDSzagFP0dIr5jkT+XenpJOXgdXA/g3/4aOUHfo9tEQngC9ANKbaB3pRwAfGM35V35 my-key"

But before we create such a user let’s check if the ID that we intent to use is available. If it is already taken we need to find the current user, terminate all his processes, change the UID and GID, then fix file ownership accordingly.

uname=$(grep $id /etc/passwd | cut -f1 -d:)
gname=$(grep $id /etc/group | cut -f1 -d:)
ps -o pid -u $uname | xargs kill -9
if [ -n "$uname" ]; then
    usermod -u 1111 $uname
    find / -user $id -exec chown -h 1111 {} \;
fi
if [ -n "$gname" ]; then
    groupmod -g 1111 $gname
    find / -group $id -exec chgrp -h 1111 {} \;
fi

Now, we are ready to create a new system user.

groupadd -g $id $username
useradd -m -s /bin/bash -u $id -g $username -G sudo,docker $username
echo "$username:$password" | chpasswd

SSH key-based authentication provides cryptographic strength that even extremely long passwords cannot offer. So, this will be our preferred method of granting access to a system and …

mkdir -p /home/$username/.ssh
echo "$ssh_pk" >> /home/$username/.ssh/authorized_keys
chmod 600 /home/$username/.ssh/authorized_keys
chown -R $username:$username /home/$username

… we make sure the above is the only method of authentication by changing the OpenSSL daemon configuration.

sed -i "s/^PasswordAuthentication yes/#PasswordAuthentication yes/g" \
    /etc/ssh/sshd_config

The last thing we may want to do is to allow privileged operations without password. This may come handy while the same system account is used to perform other automated tasks that normally would prompt for a user password.

echo "$username ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/$username

There we have it. A simple way to test it could be by loading the private key locally using the ssh-add command and trying to ssh into the server.

In my next blog post I will show how to create a minimal Ansible orchestration script.

An Alternative Approach to Estimates

Sun, 03 Jul 2016 21:18:13 +0100

Problem

A while ago I was asked to plan one of the last phases of development on a project that required re-architecture of the data access layer. One of my tasks was to estimate an effort to replace code that communicates with a legacy back-end. The new code, instead of directly connecting to a database should consume JSON-based REST API endpoints. Due to time constraints and to mitigate the risk to bring the service down this change supposed to be done in as non-invasive way as possible.

Objectives

Functionality of the application must remain unchanged for the end user

Facts

It is a simple MVC application built upon a reach domain model
Books like Design Patterns and Clean Code were probably not that popular at the time of writing the software

Issues

Developers’ skills in our team differ much
Complexity of the code that needs to be refactored varies from module to module
We have never done that before

Assumptions

We know the product already
Most of the code logic and flow remain the same
It should take no longer to refactor the code than implementing that functionality from scratch
A lot of work is repetitive and follows a pattern

How to take the above factors into account and produce accurate estimates for the management?

Solution

I was not able to find anyone who faced similar technical problems with the platform we use. This tells me something about our design, anyway… Yes, I heard about COCOMO II - Constructive Cost Model. However, I still decided to come up with my simplistic formula.

\(\scriptsize { \sum_{i=0}^n componentManDays\_i = totalManDays }\) \(\scriptsize { \frac{linesOfCode\_i}{avgLinesOfCodePerHour \times 6h} \times complexityFactor\_i \times contingency = componentManDays\_i }\)

Why? Because whichever method is used the outcome is always a guesstimate. I found out that it is so much dependent on motivation of individual team members as well as their willingness to learn and contribute. This can not be expressed by any mathematical equation.

I usually add 20% contingency to my calculations and set complexity factor to cf=1 for a simple code in higher layers of an application architecture, cf=2 for components that require more analytical and problem solving skills and up to cf=3 for tasks that require attention of a polyglot programmer.

Automation

After considering a manual approach of producing my estimates for each module and component I decided to automate that process. Quick, and in my opinion relatively reliable solution was to base the calculations on an ability to change number of lines of code by an average developer in our team in a selected period of time. There are number of issues with this approach. For example, data for the empirical analysis must come from a project with a comparable architecture, technology stack, complexity and codebase. Fortunately, we have been working on this software already for over a year delivering new functionality. So, all the data I needed were in the version control system… The only thing I needed to do is write a script that does the rest of the work for me.

Here is the usage example followed by some of the Bash functions to help to extract relevant information from Git. I used an open source project to produce the output.

$ git_print_stats 1y # for Linux use "1 year"
Developer  1       1                     46 +23:-23
Developer  2       1                     79 +44:-35
Developer  3       0                        0 +0:-0
Developer  4       5                      46 +40:-6
Developer  5       0                        0 +0:-0
Developer  6       1                        2 +1:-1
Developer  7       0                        0 +0:-0
Developer  8       0                        0 +0:-0
Developer  9       0                        0 +0:-0
Developer 10       1                        2 +1:-1
Developer 11       3                       17 +9:-8
Developer 12       2                      61 +57:-4
Developer 13      30                   545 +455:-90
Developer 14      30                   545 +455:-90
Developer 15       4                   117 +101:-16
Developer 16       1                        4 +2:-2
Developer 17       0                        0 +0:-0
Developer 18       1                      15 +13:-2
Developer 19       6                     79 +63:-16
Developer 20       3                       16 +8:-8
$ git_calc_avg_changes_per_dev 1y
78
$ source_count_lines ./module/A *.ext
3595

Calculate average line changes per developer in a given period of time.

function git_calc_avg_changes_per_dev()
{
    data=$(git_print_stats "$1" --csv | awk -F',' '{ print $3 }')
    sum=0; i=0
    for n in $data; do
        sum=$(($sum + $n)); ((i++))
    done
    echo $(($sum / $i))
}

Print number of commits and line changes for each individual contributor.

function git_print_stats()
{
    OLDIFS=$IFS; IFS=$'\n' #'
    for committer in $(git_list_committers); do
        cc=$(git_count_commits "$committer" "$1")
        cl=$(git_count_line_changes "$committer" "$1")
        if [[ $* == _"--csv"_ ]]; then
            al=$(echo "$cl" | awk '{ print $1 }')
            dl=$(echo "$cl" | awk '{ print $2 }')
            printf "\"%s\",%s,%s,%s\n" "$committer" "$cc" $al $dl
        else
            printf "%40s %7s %30s\n" "$committer" $cc "$cl"
        fi
    done
    IFS=$OLDIFS
}

List all contributors.

function git_list_committers()
{
    git log --all --format='%cN' | sort -u
}

Return number of commits for a given author.

function git_count_commits()
{
    git log \
        --author="$1" \
        --since=$(date_ago "$2") \
        --until=$(date +%Y/%m/%d) \
        --no-merges \
        --pretty='%h [%s] <%an>' \
        --abbrev-commit \
    | wc -l | tr -d '[[:space:]]'
}

Return number of line changes for a given author.

function git_count_line_changes()
{
    git log \
        --author="$1" \
        --since=$(date_ago "$2") \
        --until=$(date +%Y/%m/%d) \
        --no-merges \
        --pretty='%h [%s] <%an>' \
        --abbrev-commit \
        --numstat \
    | awk 'NF==3 \
        { plus+=$1; minus+=$2; total+=$1+$2 } END \
        { printf("%d +%d:-%d\n", total, plus, minus) }'
}

Calculate date in the past from now.

function date_ago()
{
    if [[ "$OSTYPE" == "darwin"* ]]; then
        # 1y, 12m, 52w, 365d, etc.
        date -v-$1 +%Y/%m/%d
    else
        # 1 year, 12 months, 52 weeks, 365 days, etc.
        date +%Y/%m/%d -d "-$1"
    fi
}

Count recursively all lines in files for a give file type.

function source_count_lines()
{
    find $1 -name $2 -print0 | xargs -0 cat | wc -l
}

Hello, World!

Fri, 04 Mar 2016 07:21:52 +0000

I decided to blog. This is long overdue. I should have started this years ago. This begs the question why didn’t I? I code at work I code at home. Time is very precious for me… and yes, there are more important things in live than a hobby. But I’m going to try anyway!

There is an objective, self-improvement. Continuous learning is part of being a good programmer. The world around us changes quickly. Coping with change is no longer sufficient. We need to embrace it.

I also believe that keeping notes of what I do will help me gain better understanding of the problems I solve. Maintaining good reading habits and writing a lot of code is one thing. But sharing the knowledge and being able to explain all of that to others requires deep insight - here is my challenge!