“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.

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`

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.