And that makes this, what, the 100th package management solution for Python? A big reason why Python package management sucks is because there are as many package managers as there are frameworks in JavaScript. Nobody ever knows what is the standard, and by the time that information propagates, it is no longer the standard.

I believe and hope that uv settles this discussion.

Is it really such a big deal that there are multiple "good enough" solutions available? I understand it is suboptimal, especially for beginners, but dependency management in Python is a solved problem for a while now. And also there are not that many solutions. Previously Poetry was the best, now uv is looking to take its place. Not 100 different solutions imo.

That's why I have a requirements folder with separate files (eg - dev.txt, prod.txt) for various installation needs. If you want to include test dependencies in development, just add it into the file like you're installing a regular requirements file:

  -r test.txt

And, to double-down, if you read the pip documentation (the second sin of software development?), you can use things other than pip freeze. Like,

   python -m pip list --not-required 

That option flag is pretty nice because it excludes packages that aren't dependencies (aka - the primary packages that you need). If you do that you don't to worry about dependency management as much.

You can use 2 separate requirements files no?

Pip install -f requirements.txt

Pip freeze > requirements.lock.txt

Pip install -f requirements.lock.txt

Yes, except they should be used together, like this.

  pip install -r requirements.txt -c requirements.lock.txt 

(Typically you would call that file constraints.txt)

It must be done within one single install command. If you do it twice you can end up with version conflicts during the first install and the second install will either fail or start uninstalling stuff before it retries to find a compatible version.

Rants that pip does not support lockfiles are mostly uneducated, no judgement in that, because it's so easy to miss when it's not the default and the documentation doesn't mention this crucial feature until very late in the chapters.

99% of all pip complaints would be resolved if they only introduced a convention that constraints.txt was automatically detected and installation failed if not found, unless providing a --i-dont-care-about-lockfiles argument.

Is the same constraints.txt file generated across platforms? That not being the case makes it much harder—impossible in many cases—to check them in.

uv solves this problem by generating lockfiles for the superset of all platforms, as do most other modern package managers.

That's a bad developer experience. I'd rather just use uv.

A few lines of shell script remedies that rather nicely. And there will be times when you need to choose between installing from fully resolved, pinned dependencies versus abstract immediate ones.

uv solves this better, including supporting Windows, and with significantly better error reporting. It even installs Python for you. uv also has platform-independent lockfiles and a number of other features. Oh, and it's a lot faster as well.

Have higher standards for your devtools.

Nix solves this better, including supporting Windows, and with significantly better error reporting. It even installs Python for you. Nix also has platform-independent lockfiles and a number of other features. Oh, and it's a lot faster as well. Have higher standards for your devtools.

Nix is quite a bit harder to use, and absolutely does not support Windows. (WSL is nice, but does not count as supporting Windows.)

Nix is also what I like to call "totalizing" — in order to use Nix you must fit everything into the Nix world. This has many advantages (as do Buck2 and Bazel which are similarly totalizing), but is also quite onerous and might not be desirable.

Further, I believe Nix makes pinning to old versions of a dependency, and maintaining custom patches on top of a dependency, somewhat difficult.

Good developers don't care about developer experience, we care about user experience.

Get it done and move on.

Write the 3 commands in a shell file called "build.sh" if it's too much trouble.

Boom done.

I'm a builder of, among other things, developer tools. From my perspective, the developer experience is the user experience I'm delivering.

From the perspective of someone new to programming, the developer experience we deliver is the user experience they encounter. It is extraordinarily important that it be good.

Again, I would simply rather use uv -- I really appreciate the thoughtful engineering that's gone into it. It solves this problem completely, along with many others. (For example, uv.lock is platform-independent.)

I'm okay with the occasional workaround, but I think we should generally expect, and aim for, excellence with our tools.

No good developers know and understand their tools. They care for them and they learn about them. Wood carvers don't use butter knives because "good woodcarvers don't care about their experience while woodcarving".

good developers do not care, great ones do

I think 'pip freeze' was introduced later and requirements.txt was not designed with such a use in mind. pipenv and other tools have lockfile equivalents for a while.