
pyproject.toml for an LLM project
I’m a uv convert.
It’s a much faster way to set up isolated virtual environments for Python than other methods that I’ve used, including Anaconda and the venv + pip combination.
Anaconda Baseline #
For my current course on AI Engineering the code expects the environment to be fully managed using Anaconda. I have zero problem with that. It’s all nicely packaged up in a single file:
environment.yaml
| |
It’s all very clear what this project relies on. But I don’t use Anaconda: I use asdf to manage languages and runtimes, including Python. And I’ve started using uv for my Python projects.
Using the right Python #
First I use asdf to install the right Python version.
I decided to use a more recent version of Python that the Anaconda baseline.
| |
The last line sets the Python version for the current directory by creating a .tool-versions file:
| |
If you want to use uv to manage your Pythons, you can totally do that by following their detailed instructions.
I use asdf for all of my languages and runtimes, so I prefer to use it for setting project-local versions.
Here’s that Python version for my project:
| |
Adding uv Support
#
I working in an existing git repository that I don’t want to litter with all kinds of uv-isms, like a new README.md or a dedicated directory.
I just want to use uv alongside my asdf-managed Python versions.
Basic Configuration #
First, let’s use uv in the most minimal way possible:
| |
This does exactly one thing: it creates a basic project file in the current directory (.) rather the the typical behaviour of creating a new directory:
toml-bare.toml
| |
Add Dependencies #
This is where I think uv shines: it’s incredibly fast to detect, resolve, and install dependencies.
pip just takes an age in the build process once it’s downloaded whereas uv, as far as a understand, has prebuilt binaries for the dependencies.
First attempt:
| |
Oh jeez. I misspelled streamlit!
But hey, and least uv created a virtual environment for me!
Let’s try again:
| |
So this whole thing just took less that one minute to fetch the same things that Anaconda expects, including a build of one library that hadn’t been cached in advance.
If you want to read all the gory details, run uv tree and get a sense for the sheer number of dependencies that were installed.
If you really want to know what the project depends on, uv did also create a uv.lock file.
It’s dense!
Using uv
#
If I were to check in my changes to the git repo, they’d be quite modest:
| |
Three files that will let a subsequent contributor to do the following.
- Install uv.
- Set up the correct Python and virtual environment. That could be with asdf, uv, or whatever makes you happy.
- Run
uv syncand get blazing fast results.
If you discover that there’s a missing dependency, uv add ... comes to the rescue, and you’d commit the updated pyproject.toml and uv.lock to your repo.
Conclusion #
There’s nothing wrong with Anaconda, but it’s not the only way to manage Python projects.
uv is a lightweight alternative that can be used to manage Python projects their dependencies.
See Also
- Python, SQL, and data eng til
- OSM and Python til
- A Bit of Fastapi for Auth blog
- 2021-05-15 til
- 2021-05-05 til