Derk Weijers on Qstars IT Blog - Cloud, Kubernetes & Software Engineering

Pre-commit vs Prek - The Differences

Mon, 02 Mar 2026 10:00:00 +0200

If you’ve been working with Python (or really any language) for a while, chances are you’ve used pre-commit. It’s been the de facto standard for managing git hooks for years. You define your hooks in a .pre-commit-config.yaml, run pre-commit install, and you’re good to go. It handles the installation and execution of hooks written in any language, without requiring root access.

But recently, as I found out at FOSDEM, a new tool has been making the rounds: prek. It’s like a version of pre-commit, built in Rust. And if you’ve been following the Python ecosystem, you’ll notice a trend here. First we got Ruff as a replacement for Flake8, Black, and isort. Then uv came along to replace pip venv (and maybe even Poetry). Now prek is here to speed things up as well.

The Rust rewrite of pre-commit is gaining traction fast. For a couple of my projects I decided to give prek a shot and see how it compares to good old pre-commit. Let me walk you through the differences.

A quick recap

pre-commit

pre-commit has been around since 2014 and has a massive ecosystem. It’s a multi-language package manager for git hooks. You specify the hooks you want, and pre-commit manages everything: downloading the tools, setting up isolated virtual environments, and running the hooks on every commit.

A typical configuration looks like this:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: check-yaml
      - id: end-of-file-fixer
      - id: trailing-whitespace
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.8.0
    hooks:
      - id: ruff
      - id: ruff-format

Getting started is straightforward:

1
2

pip install pre-commit
pre-commit install --install-hooks

That’s it. Now every time you commit, your hooks will run.

prek

prek is a drop-in replacement for pre-commit, built in Rust by j178. It’s designed to be faster, dependency-free, and fully compatible with your existing .pre-commit-config.yaml. That last part is key: you don’t have to change your configuration at all.

Installation is just as simple:

# Using uv (recommended)
uv tool install prek
# or
uv add --dev prek

# Or via pip
pip install prek

The migration? Two commands:

1
2

pre-commit uninstall
prek install

That’s it. No configuration changes, no compatibility issues. Your existing .pre-commit-config.yaml works as-is.

So why would you switch?

Speed

Let’s be real, this is the main reason. pre-commit is written in Python and creates isolated virtual environments for each hook. This architecture is robust, but it introduces overhead. Especially the initial setup can take a while.

prek is significantly faster. According to the official benchmarks, installing hooks for Apache Airflow (which has a large and complex pre-commit configuration) took about 18 seconds with prek versus 187 seconds with pre-commit. That’s roughly 10x faster. For runtime, the numbers vary but prek is consistently 2-5x faster, depending on the hooks and whether the fast path is enabled.

On the CPython codebase, running check-toml across all files:

Tool	Time (warm cache)
prek	~77ms
pre-commit	~352ms

That’s about 4.5x faster. And these numbers get more dramatic with cold caches and larger hook configurations.

Disk space

prek redesigned how hook environments and toolchains are managed. Instead of creating a separate virtual environment for each hook, it shares toolchains between hooks. The result? After installing hooks for Apache Airflow, prek used about 810MB of disk space compared to 1.6GB for pre-commit. That’s roughly half the disk usage.

No Python dependency

One of the things that has always bugged me about pre-commit is that it’s a Python tool. That means you need a Python installation to use it, even if you’re working on a Node.js or Go project. prek ships as a single binary with no dependencies. It doesn’t require Python or any other runtime.

Even better: if your hooks need Python, prek will automatically install the required version for you. No more hassle with your system Python version not matching what the hooks expect.

Parallel execution

pre-commit runs hooks sequentially. prek can run hooks in parallel based on priority. Hooks with the same priority may run concurrently, reducing the end-to-end runtime. This is especially useful when you have multiple independent hooks that don’t need to run in a specific order.

Better CLI experience

prek comes with some nice quality-of-life improvements over pre-commit’s CLI (full list):

prek run --directory <dir> runs hooks for files in a specific directory. No more piping git ls-files into xargs.
prek run --last-commit runs hooks on files changed in the last commit.
prek run [HOOK] [HOOK] lets you select and run multiple hooks at once.
prek list gives you a nice overview of all configured hooks and their descriptions.
prek auto-update supports --cooldown-days to avoid picking up brand-new releases immediately — a neat defense against supply chain attacks.

Monorepo support

If you work with monorepos, prek has built-in workspace mode. Each subproject can have its own .pre-commit-config.yaml file, and prek handles running hooks across all of them. This is something pre-commit doesn’t support natively, and it doesn’t seem this will be implemented soon.

Built-in hooks

prek implements some common hooks from pre-commit-hooks natively in Rust (see the list). These are faster than their Python counterparts and can run offline with repo: builtin, which is not available in pre-commit.

Where pre-commit still wins

It wouldn’t be fair to not mention the areas where pre-commit still has the upper hand.

Maturity and ecosystem: pre-commit has been around for over a decade. It has extensive documentation, a massive community, and a proven track record. When something goes wrong, you’re more likely to find an answer on Stack Overflow.

Language support: While prek supports most commonly used languages, some are not yet fully supported for drop-in parity with pre-commit. Check the Language Support page for the current status.

pre-commit.ci: If you use pre-commit.ci for running hooks in CI and auto-fixing pull requests, there’s no equivalent for prek yet. That said, there is a prek GitHub Action available for CI integration.

Battle-tested edge cases: pre-commit has handled just about every obscure configuration and edge case out there. prek is newer and, while it’s already used by projects like CPython, FastAPI, Apache Airflow, and Django, it might not handle every niche scenario yet.

Who’s already using prek?

The adoption list is actually quite impressive for such a young tool. Projects like CPython, FastAPI, Apache Airflow, Ruff, and Home Assistant have either adopted prek or are in the process of switching. That’s a pretty strong signal.

Conclusion

If you’re already using pre-commit and everything works fine, there’s no rush to switch. pre-commit is a solid, battle-tested tool that will continue to serve you well.

However, if you find yourself annoyed by slow hook installations, if you’re working in a monorepo, or if you just like your tools to be fast, prek is absolutely worth trying. The migration path is painless and fully reversible. Give it a spin, see if it works for your setup, and enjoy the speed boost.

The trend of rewriting Python tooling in Rust isn’t slowing down, and prek fits right into this movement alongside Ruff and uv. It’s exciting to see the Python ecosystem getting faster without sacrificing the developer experience we’ve come to expect.

uv has pushed a BIG update

Thu, 22 Aug 2024 10:00:06 +0200

Python’s ecosystem is constantly evolving, with tools and libraries emerging to address the growing needs of developers. Among these tools is the uv package manager, an innovative approach to handling Python dependencies. The recent release of uv 0.3.0 introduces a range of exciting features and improvements, solidifying its position as a cutting-edge tool for Python developers. In this post, we’ll take a closer look at what’s new in uv 0.3.0 and how it can streamline your development workflow.

What is uv?

If you’re unfimiliar with uv that’s okay. It hasn’t been around for a long time and only recently started to gain traction. The uv package manager is designed to provide a modern and efficient way to manage Python packages and dependencies. It aims to simplify the process of creating and maintaining Python environments, offering a more intuitive and less error-prone alternative to traditional tools like pip and venv. By combining dependency resolution, environment management, and packaging into a single tool, uv empowers developers to manage their Python projects with ease. It’s inspired by Cargo (the package manager for Rust) and its ultimate goal is to be a tool that can do anything related to manage your Python projects. Since it’s written in Rust, it’s extremely fast.

Key Features and Updates in uv 0.3.0

The 0.3.0 release of uv introduces several new features and improvements, reflecting the feedback from early adopters and the project’s ongoing commitment to innovation. Here are the key updates:

Enhanced Dependency Resolution

One of the most notable enhancements in uv 0.3.0 is the improved dependency resolution algorithm. This update addresses some of the common pain points associated with dependency conflicts by offering more sophisticated resolution strategies. The new algorithm is faster and more accurate, reducing the likelihood of dependency clashes and ensuring that your environment is both stable and reproducible.

Lockfile Support

uv 0.3.0 introduces support for lockfiles, a much-requested feature. Lockfiles allow you to freeze the exact versions of all dependencies in your project, ensuring that anyone who installs your project’s dependencies gets the same versions that you used during development. This is particularly valuable for collaborative projects or deployment scenarios where consistency across environments is critical.

Customizable Environments

With version 0.3.0, uv now allows for more customization of your Python environments. You can specify different environments for development, testing, and production, each with its own set of dependencies and configurations. This feature streamlines the process of switching between different stages of your project, making it easier to maintain separate environments without conflicts.

Improved CLI Experience

The command-line interface (CLI) in uv 0.3.0 has been refined for better usability. The new release introduces more intuitive commands, clearer error messages, and enhanced help documentation. These improvements make it easier for both new and experienced users to navigate the tool and perform common tasks quickly.

Expanded Plugin Ecosystem

Another significant update is the expansion of the uv plugin ecosystem. The 0.3.0 release includes several new plugins that extend the functionality of uv, offering features like integration with popular CI/CD pipelines, automatic virtual environment creation, and support for advanced packaging formats. These plugins make uv even more versatile, allowing developers to tailor it to their specific needs.

Why Should You Checkout uv?

The release of uv 0.3.0 underscores the tool’s potential to become a staple in the Python development community. Its focus on simplicity, performance, and flexibility makes it an attractive option for developers who want to streamline their workflow and reduce the overhead associated with managing Python dependencies. Whether you’re working on a small personal project or a large-scale enterprise application, uv provides the tools you need to maintain clean, reliable, and reproducible environments.

As stated before, uv is extremely fast. This table (credits: from the uv repo) compares installing Trio’s dependencies with a warm cache.

Name	Time (less is better)
uv	0.06s
Poetry	0.99s
pdm	1.90s
pip-sync	4.63s

Getting Started with uv 0.3.0

If you’re new to uv or looking to upgrade to the latest version, getting started is straightforward. You can install uv using pip:

# On macOS and Linux.
$ curl -LsSf https://astral.sh/uv/install.sh | sh

# On Windows.
$ powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# With pip.
$ pip install uv

# Create a project - uv will automatically fetch Python versions as needed, you don't need to install Python to get started
uv init helloworld

# Install dependencies
uv add flask

# Create the virtualenvironment and install the dependencies
uv sync

# Run Ruff without adding it as dependency
uvx ruff check

# Or install ruff as tool in the virtualenvironment
uv tool install ruff
ruff check

Once installed, you can initialize a new project or manage existing dependencies with simple, intuitive commands. The official (and majorly updated) documentation provides comprehensive guidance on how to leverage the new features introduced in 0.3.0.

Conclusion

The uv package manager continues to evolve with the release of version 0.3.0, bringing with it a host of features that make Python dependency management more efficient and user-friendly. Especially the new project, tool, script and python sub-commands will make the developer experience of using uv a whole lot smoother. Uv is now one step closer to being a full-fledged Python project manager.

For more info about uv, make sure to checkout the official repository!

Recap EuroPython 2024

Wed, 24 Jul 2024 10:00:06 +0200

July came around again, which meant it was time for another edition of EuroPython! Like last year, it was held in the beautiful city of Prague.

AI and Machine Learning

Like with all (technical) conferences in the past year, AI is dominating the landscape. While there was a lot of focus on AI and LLM during EuroPython 2023, it felt like there was more room for other topics this year. Of course, AI wasn’t completely gone, especially RAG was pretty popular this year.

Typings

While this is a bit of controversial topic within the Python landscape, adding type annotations to your codebase is becoming more popular. Especially with bigger codebases, adding type annotations can improved the readability, integrity and maintainability of a codebase. During one of the talks, given by Kir Chou, we dived into PEP 729 which is a proposal to govern the typing process. While it’s still in-progress, it has support from all the major type checkers to create a consistent typing experience.

If/when this PEP gets accepted, type checkers should become more robust and consistent, resulting in more resilient code.

Talks

In general, the talks were really good. The amount of proposals was huge (a new record, even!) so there was more than enough to choose from. A lot of talks were from a personal perspective from people who just wanted to share experience on certain topics. It was nice to see they included real-life use-cases. For example, the talk How to sell a big refactor or rewrite to the business? included about 5 use-cases when a company decided to do a rewrite/refactor including the reasoning and strategy. This is incredibly helpful if you’re dealing with this situation as well.

The social event is one of the highlights of the conference. It’s a paid event to relax, network and hangout with friends from earlier EuroPythons. This year it was being held in an awesome location, the historic Gabriel Loci ex-monastery (which also was the location for PyCon CZ!).

This year’s social event was different than others we’ve attended. Everyone was free to bring their instruments and boardgames. You could either sit outside (which is pretty nice in terms of temperature this time of year) and have a chat with each other, or sit inside and play boardgames. There as also a jam session for those who brought their instruments.

This event is were friendships are made!

Sprints

The sprints were a bit new to us. Normally we’d spend the weekend in the city the conference is held in, however since this was my 5th time in Prague and we heard really good things about the sprint weekend, we decided to join this year.

The sprint weekend is a weekend where open-source projects invite EuroPython attendees to join in their coding efforts. All skill levels are welcome to join as most issues range from beginner to expert. This year, the sprint weekend was held in the University of Economics of Prague. There was food, drinks, good wifi and cool projects to work on. In terms of networking, this was the perfect place to do so! We met awesome people and got talked with some of the people who gave talks or are EuroPython/PyCon organizer.

This is definitely something we´d like to participate on again next year!

The projects we’ve worked on:

Bas CPython
Benny MicroPython
Derk Falcon

DEI

EuroPython has been actively promoting Diversity, Equity, and Inclusion (DEI) in its community. This is one of the areas where it differs from other conferences (that we attend) and it’s highly integrated into the program and events.

Here are some key aspects of DEI at EuroPython:

Code of Conduct

EuroPython enforces a comprehensive Code of Conduct to ensure a welcoming and harassment-free environment for all participants. This includes clear guidelines on expected behavior and steps for reporting incidents.

Diversity Grants

The conference offers diversity grants to support individuals from underrepresented groups, helping them to attend the conference by covering expenses such as travel and accommodation.

Diverse Speaker Line-up

EuroPython strives to include a diverse range of speakers, ensuring representation from different backgrounds, genders, and communities. They actively encourage and support new and diverse voices in their call for proposals.

Workshops and Panels on DEI

The conference often includes workshops, panels, and discussions focused on DEI topics. These sessions are designed to raise awareness, share best practices, and promote actionable steps towards inclusivity within the Python community.

Community Building Activities

EuroPython fosters a sense of community through various networking events and activities that are inclusive and accessible to all participants, aiming to build a supportive and diverse community around Python.

Accessibility

The conference venues and materials are chosen and designed with accessibility in mind, ensuring that participants with disabilities can fully engage with the event.

Childcare Facilities

Recognizing the importance of supporting attendees with families, EuroPython often provides childcare facilities, making it easier for parents to participate in the conference.

Playlist / Videos

If you’d like to see the sessions, the initial version of the YouTube playlist is now available!

Going Distroless

Thu, 09 May 2024 10:00:06 +0200

You probably know this saying:

There is no such thing as “cloud” - The cloud is just somebody else’s computer.

And I must admit that’s exactly what I thought when I first heard about distroless images. But what is distroless and what are the pros and cons? Let’s dive in!

What is distroless

“Distroless” images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.

Distroless images are very small images. They just contain your application and their runtime dependencies. They don’t contain extras like shells and package managers - basically everything you would typically find in Linux distributions.

That being said, distroless images still contain a distribution - In the end there’s no such thing as no distro.

Why distroless

When I first heard of distroless, it was because I was investigating the high vulnerabilities count in one of my projects. The client uses multiple tools to check for issues like code smell, missing tests and vulnerabilities in container images.

I reached out to the team that’s deploying these tools to check what can be done, since we’re using official (Python) images most vulnerabilities didn’t impact our code/application but still blocked our CI/CD pipelines. They introduced distroless images, something that was kind of new to me. They would probably solve most of our issues, but there’s got to be a catch, right?

Google, one of the contributors to distroless, says the following about distroless:

Restricting what’s in your runtime container to precisely what’s necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.

Distroless images are very small. The smallest distroless image, gcr.io/distroless/static-debian11, is around 2 MiB. That’s about 50% of the size of alpine (~5 MiB), and less than 2% of the size of debian (124 MiB).

Examples

Time to checkout some distroless examples. The tests below are ran locally. After building an image, Trivy is used to run a security scan.

Rust (Rocket)

Let’s start with benchmarking a normal Rust 1.77 image. It’s a basic Rocket application with just a single endpoint. The base image used is rust:1.77, and the OS is fully updated. This gives the following results:

1
2
3

rust-fat
==================
Total: 1056 (UNKNOWN: 5, LOW: 501, MEDIUM: 438, HIGH: 107, CRITICAL: 5)

Let’s build the same application, but now with a distroless image:

1
2
3

rust-distroless
=============================
Total: 21 (UNKNOWN: 0, LOW: 13, MEDIUM: 7, HIGH: 1, CRITICAL: 0)

Not zero, but definitely better. Let’s compare the image sizes:

Name	Size
rust-fat	2.45GB
rust-distroless	39.1MB

That’s quite a difference! Let’s see some more examples.

Java (Micronaut)

A simple Maven image:

1
2
3

mvn-fat
======================
Total: 75 (UNKNOWN: 0, LOW: 55, MEDIUM: 20, HIGH: 0, CRITICAL: 0)

v.s. a distroless image:

1
2
3

mvn-distroless
============================
Total: 24 (UNKNOWN: 0, LOW: 18, MEDIUM: 2, HIGH: 3, CRITICAL: 1)

Name	Size
mvn-fat	414MB
mvn-distroless	236MB

Python (Flask)

And then a bit of a tricky one. So far we’ve used languages who compile/package their dependencies with the executable they ship. Python works differently so needs a few more steps.

Lets start with a simple Python API (Flask with Gunicorn):

1
2
3

python-fat (debian 12.5)
==================
Total: 124 (UNKNOWN: 0, LOW: 71, MEDIUM: 39, HIGH: 13, CRITICAL: 1)

And now the distroless image:


python-distroless (debian 12.5)
==================
Total: 70 (UNKNOWN: 0, LOW: 23, MEDIUM: 30, HIGH: 16, CRITICAL: 1)

That’s definitely less, but still quite a lot (and the critical one is still present). As can be seen in the image we disable creating a virtual environment and we need to copy the entire /usr/local/lib/python3.11/site-packages over to the distroless image (to get the dependencies “installed”). We also need to explicitly update the PYTHONPATH variable, to tell Python where to look for packages and modules.

Lastly, sizes. The resulting image is just a bit smaller.

Name	Size
python-fat	259MB
python-distroless	134MB

Conclusion

Distroless images can greatly reduce the size of images. Since it removes a lot of OS level tooling that’s (often) not needed, it can also remove quite some vulnerabilities.

However, since it removes so much from the image it also makes it harder to debug. Since there is no shell, you can’t exec into the container to see it’s content or troubleshoot a process. Furthermore, if you need some OS-level dependency installed it gets quite harder. You can’t run sudo apt install somepackage since there’s no package-manager installed either.

Distroless images are not suitable for every piece of software and workload. They might require a bit more configuration and maintenance. But, as with many things in IT, it’s a great tool for the right jobs.

Google’s distroless images are built with Bazel. If you’d like to apply more customizations or automate the process of creating images, I highly encourage to checkout the docs.

In a future blog we’ll discuss other images that can be used to create safe and clean Docker images.

Combining Poetry and Conda

Sun, 11 Feb 2024 13:22:22 +0100

For one of my clients I had to convert a couple of pip-managed repositories to Poetry-managed ones. When I got to the last repo, there was one catch: it required Conda as well. This is quite straightforward, with the help of some packages and a couple of config changes.

Pip v.s. Poetry v.s. Conda

Lets quickly recap the three tools we will discuss today.

pip

Pip is probably one of the most known package managers for Python. It enables developers to fetch and install Python packages from either the internet or a private repository. Pip has been the standard for a lot of years and will probably being used for many years to come.

Poetry

In the past few years Poetry quickly gained traction. Build upon pip, it’s a package manager on steroids. With the help of pyproject.toml files you can define your packages (either individually or in groups), set the configuration for groups of packages, define settings for your favourite linters and tools and define the environment to build your packages. It can (and will so by default) also create your virtual environments.

Conda

Then there’s also Conda. Conda has a lot of similarities with Poetry. One of the benefits of Conda (and this is also the reason my client uses it) is that repositories like conda-forge contain pre-compiled packages; something that’s not always the case with PyPi (the public package repository that both pip and Poetry use by default).

Combining Poetry & Conda

When picking up this story, it sounded pretty straightforward. However, one of the issues is that both Poetry and Conda are package managers, as well as environment managers that can conflict with each other quite easily. So how do we set this up?

Since Poetry is quite straightforward to configure to the needs of Conda, we’ll use Conda as the base environment. Then we modify Poetry to use this environment as well.

Lets start with setting up a base environment.yml to define our Conda setup:

name: poetry-and-conda
channels:
  - conda-forge
dependencies:
  - python==3.11.*
  - gmsh
  - conda-lock
  - poetry
platforms:
  - linux-64
  - osx-64
  - win-64

These packages are just some examples, however there are a few important things to note here:

We define a Python version, this should be kept the same as what we will define in our pyproject.toml.
poetry will be installed as a dependency as well. This ensures that the poetry command (which we will use later) is used in the context of the Conda environment.
We define platforms which will be used for our conda lock file, which will be generated with the conda-lock tool. You can remove the platforms you don’t need.

With this out of the way we can configure a lock file. The lock file will be used to create reproducible environments across installations. We create the lock files with a temporary environment:

conda create -p /tmp/condaenv -c conda-forge python=="3.11.*" conda-lock
conda activate /tmp/condaenv
conda-lock -k explicit
conda deactivate
rm -rf /tmp/condaenv

So what’s happening here? We create an environment, using the conda-forge channel, and setup Python 3.11 (the same that we’ve defined in the environment.yml) and conda-lock. We will then activate the environment, run the conda-lock command which will pick-up the dependencies from the environment.yml, resolve them and put their exact versions and hashes into a file called conda-linux-64.lock. Using this file, we can create reprodusable environments, which is great when working in teams (everyone will get the exact same version of packages when setting up the environment). After that’s done we deactivate the environment and remove it from the system.

Now it’s time to get the real environment up and running!

`1`	`conda create --name poetry-and-conda -c conda-forge --file conda-osx-64.lock`

First, we’ll generate the environment from the lock file. We’ll give it a name, specify the conda-forge channel and make use of the lock file we generated earlier to install the required packages. Please note that I’m using the conda-osx-64.lock file. If you’re on Windows or Linux, you should use one those flavours instead. If you’re just using a single platform, you can remove the others from the environment.yml file.

Now it’s time to activate the environment and configure Poetry:

conda activate poetry-and-conda

# Verify which Poetry we're using
which poetry
# Note that this will point to Poetry installed in the environment,
# not my globally installed Poetry.
# /opt/homebrew/Caskroom/miniconda/base/envs/poetry-and-conda/bin/poetry

# Make sure Poetry doesn't create another environment
poetry config --local virtualenvs.create false

# Start a Poetry project
poetry init -n

By running poetry config --local virtualenvs.create false we will get a poetry.toml that contains some local config that will prevent the creation of virtual environments for just this project. If you’re working in a team it’s important to commit this to your repository as well. When running the init command, make sure the Python version matches with what you’ve used to setup the Conda environment.

We can now use Poetry to install PyPi (or private repository, when configured) packages.

1
2

poetry add flask flask-login
poetry add --group dev pytest

Since we’ve configured Poetry to not create an environment for this project, it will install the packages in the current environment - the Conda environment in this case.

With the setup above, we’ve added both conda(-forge) packages and PyPi packages. They’re all installed in the same environment, so the interpeter is able to find the packages, regardless of which tool installed them. Now we can create a webapp (an API for example) with Flask (as installed with Poetry) that uses gmsh (that’s installed with Conda).

And that’s it! Now you’ve got a Conda and Poetry hybrid environment. I would recommend to stick with a single solution as much as possible, but sometimes you’re required to combine the two.

Derk Weijers on Qstars IT Blog - Cloud, Kubernetes & Software Engineering

Pre-commit vs Prek - The Differences

A quick recap

pre-commit

prek

So why would you switch?

Speed

Disk space

No Python dependency

Parallel execution

Better CLI experience

Monorepo support

Built-in hooks

Where pre-commit still wins

Who’s already using prek?

Conclusion

uv has pushed a BIG update

What is uv?

Key Features and Updates in uv 0.3.0

Enhanced Dependency Resolution

Lockfile Support

Customizable Environments

Improved CLI Experience

Expanded Plugin Ecosystem

Why Should You Checkout uv?

Getting Started with uv 0.3.0

Conclusion

Recap EuroPython 2024

AI and Machine Learning

Typings

Talks

Social Event

Sprints

DEI

Code of Conduct

Diversity Grants

Diverse Speaker Line-up

Workshops and Panels on DEI

Community Building Activities

Accessibility

Childcare Facilities

Playlist / Videos

Going Distroless

What is distroless

Why distroless

Examples

Rust (Rocket)

Java (Micronaut)

Python (Flask)

Conclusion

Combining Poetry and Conda

Pip v.s. Poetry v.s. Conda

pip

Poetry

Conda

Combining Poetry & Conda