(I work on uv)
As a note, you can set the default bounds for `uv add` in persistent configuration — no need to provide it every time. See https://docs.astral.sh/uv/reference/settings/#add-bounds
We prefer not to add upper bounds by default because it causes a lot of unnecessary conflicts in the ecosystem. I previously collected some resources on this back when I used Poetry :) see https://github.com/zanieb/poetry-relax#references
“Removing upper version bounds is important when publishing libraries.”
That makes total sense! The article however was written as someone creating websites, not libraries. And when I consume dependencies in my web project, I do want those upper bounds to prevent breaking changes (assuming the dependencies respect SemVer of course).
Thanks for pointing out that config, I’ve updated the article.
`uv.lock` pins exact versions (and hashes) of your dependencies.
Yes, and he is discussing how `uv lock` updates the contents of that file
Hi, out of curiosity is there a way to persistently set the `--native-tls` flag? UV always fails without it because of Zscalar configurations at my day job.
Also, is there any plan to add support for specifying that a compatible python version for a specific architecture? One of the packages I maintain at work has to use 32 bit python, and I always have to pass the `--python /path/to/32bit`
Yes you can set it via an environment variable (UV_NATIVE_TLS=true) or in your uv.toml (native-tls = true). However, check the docs, I think they are renaming it to sytem-certs.
Forgive me for asking a slightly inhaled question - Is there a way to get uv to respect `exclude-newer` in `pyproject.toml`?
When I run `uv run` it removes `exclude-newer` from pyproject.toml.
I could run `uv run —-frozen` or `uv run --exclude-newer` all the time, but that doesn’t seem quite right. Is there an idiomatic flow that I’m missing out on?
Wow thanks TIL about the « add-bounds » config! Especially useful for project where pinning to exact dependencies is crucial and easily missed by less experienced devs (end products, not libs)
Also Python projects often do not even use semantic versioning.
> In the eyes of uv, pydantic version 2, 3, and 100 are all perfectly acceptable.
Without semantic versioning, they are.