3 ms·

(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.s

by zanie 4mo 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 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 https://github.com/zanieb/poetry-relax#references

rmnclmnt 4mo ago
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)
IshKebab 4mo ago
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.
kjmr 4mo ago
“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.
- euiq 4mo ago
  `uv.lock` pins exact versions (and hashes) of your dependencies.
  - gegtik 4mo ago
    Yes, and he is discussing how `uv lock` updates the contents of that file
0x3444ac53 4mo ago
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`
- brewmarche 4mo ago
  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.
  - brewmarche 4mo ago
    Looks like I forgot to answer the other half :) Yes you can pin a specific Python like `uv python pin cpython-3.14.0-macos-aarch64-none`, it will create a `.python-version` file which will be respected when you’re in the directory.
alasdairnicol 4mo ago
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?
jeremyjh 4mo ago
The Haskell community wrestled with this for many years - may still I haven't really kept up. Last I was involved the most successful thing going on was Stackage where they encouraged no defensive upper bounds and ran continous builds on a large chunk of the most active parts of the ecosystem with every release to find actual compatibility issues, with automation to handle notifications back to owners and clear timelines if you wanted to stay in the next "LTS" release. Things now seem to be stable enough that you just need the Cabal solver - but I suspect the broad nightly builds and visible failures/blockages probably help keep the ecosystem solvable.

by zanie 4mo ago

rmnclmnt 4mo ago

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)

IshKebab 4mo ago

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.

kjmr 4mo ago

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

euiq 4mo ago
`uv.lock` pins exact versions (and hashes) of your dependencies.
- gegtik 4mo ago
  Yes, and he is discussing how `uv lock` updates the contents of that file

0x3444ac53 4mo ago

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`

brewmarche 4mo ago
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.
- brewmarche 4mo ago
  Looks like I forgot to answer the other half :) Yes you can pin a specific Python like `uv python pin cpython-3.14.0-macos-aarch64-none`, it will create a `.python-version` file which will be respected when you’re in the directory.

alasdairnicol 4mo ago

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?

jeremyjh 4mo ago

The Haskell community wrestled with this for many years - may still I haven't really kept up. Last I was involved the most successful thing going on was Stackage where they encouraged no defensive upper bounds and ran continous builds on a large chunk of the most active parts of the ecosystem with every release to find actual compatibility issues, with automation to handle notifications back to owners and clear timelines if you wanted to stay in the next "LTS" release. Things now seem to be stable enough that you just need the Cabal solver - but I suspect the broad nightly builds and visible failures/blockages probably help keep the ecosystem solvable.