An unbiased evaluation of Python environment and packaging tools (2023)
alpopkes.com
alpopkes.com
The problem is when you want to open-source a package. I consider myself a professional Python developer, yet I was completely overwhelmed with all ways you can manage and release a package. Hatch, poetry, rye, setup, and a million other things that can make you a waste days fighting the language.
I highly recommend this cookiecutter from Simon Willison: https://simonwillison.net/2024/Jan/16/python-lib-pypi/
I just open-sourced a project last week[0] and it took 5 minutes (after 2 days fighting other tools).
Which reminds me that I need to revisit devcontainers for my work. When I first tried them, I ran into a few rough edges which might have since been resolved.
^1 Caveat, making a package of a Python project can be a rabbit hole can be a real pita. Virtual envs are usually good enough for most stuff until I start to need a compiler in every jail. Nowadays I'm looking almost only at Go (best) or Rust because their distribution is trivial in comparison.
Otherwise, I often find myself needing to deploy Python/Node/Ruby at $WORK and I'd really rather not try to get a bunch of dev/prod machines (possibly running different OSes!) trying to use whatever the flavor of the day for managing virtual environments, interpreter versions, packages, etc. is.
I've spent waaay to much time trying to docker build a python container with various combinations of apt-get/pacman/apk + pip/conda/venv
To move up a level of abstraction, though, the official Python image pretty much does The Right Thing by default (copy requirements.txt, pip install, execute some command, etc.). Of course that isn't going to work for every scenario but it's a good place to start.
It's not a solution it's a response.
It's "This thing makes no attempt to be portable or coordinate with the rest of the world, so the only way to package it is to include a copy of it's own entire world."
There is no excuse for a python script to be a hothouse flower.
It's one thing to choose to containerize something for your own operational reasons, but something else entirely for something to be so fragile that thst's the only way it even works is just you need a copy of the devs laptop.
It's garbage.
This means trying to fit all the various use cases for packaging has been like herding cats. It's certainly not a technical problem anymore, the newer ecosystems/languages have figured it out, but it is a community/human problem. Thankfully there is now a small dedicated team that has been working on the problem for years, and progress has been made. For the most part if you stick to a single tool(poetry or rye for example) then most of your problems disappear as long as you stick to their blessed way, whatever it is.
> TL;DR: uv is an extremely fast Python package installer and resolver, written in Rust, and designed as a drop-in replacement for pip and pip-tools workflows.
> uv represents a milestone in our pursuit of a "Cargo for Python": a comprehensive Python project and package manager that's fast, reliable, and easy to use.
> As part of this release, we're also taking stewardship of Rye, an experimental Python packaging tool from Armin Ronacher. We'll maintain Rye as we expand uv into a unified successor project, to fulfill our shared vision for Python packaging.
Still super young, like you said, but it's really good for a lot of cases and now defaults to using uv under the hood I believe, which makes it quite fast.