Comment by zanie
19 hours ago
(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.
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)
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?
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.