4 ms·

uv is almost perfect. my only pet peeve is updating dependencies. sometimes I just want to go "uv, bump all my dependencies to the as latest version as possible

uv is almost perfect. my only pet peeve is updating dependencies. sometimes I just want to go "uv, bump all my dependencies to the as latest version as possible while respecting their constraints". I still haven't found an elegant way to do this, but I have written a script that parses pyproject.toml, removes the deps, and invokes `uv add --upgrade` with them. other than that, it's invaluable to me, with the best features being uvx and PEP 723

jmtulloss 1y ago
Does `uv lock —upgrade` not do what you want?
- incognito124 1y ago
  Unfortunately, no. Only `uv.lock` gets updated, but the dependencies in `pyproject.toml` are frozen at their original constraints. What I want is, if my project depends on `package1==0.4.0` and there are new versions of package1, for uv to try install the newer version. and to do that for a) all the deps, simultaneously, b) without me explicitly stating the dependencies in the command line since they're already written in the pyproject.toml. an `uv refresh` of sorts
  - wtallis 1y ago
    > What I want is, if my project depends on `package1==0.4.0` and there are new version of package1, for uv to try install the newer version. I think you're just specifying your dependency constraints wrong. What you're asking for is not what the `==` operator is for; you probably want `~=`.
  - Eridrus 1y ago
    Why not depend on package1>=0.4.0 rather than specifying an explicit version? Then uv will upgrade it to the latest version. pyproject.toml is meant to encode the actual constraints for when your app will function correctly, not hardcode exact versions, which is what the lockfile is for.
    - IshKebab 1y ago
      Because then you don't get to use the new features in 0.5.0. Though I do think with Python in particular it's probably better to manually upgrade when needed, rather than opportunistically require the latest, because Python can't handle two versions of the same package in one venv.
      - lucky_cloud 1y ago
        Then make your dependency package1>=0.4 https://packaging.python.org/en/latest/specifications/dependency-specifiers/#dependency-specifiers https://packaging.python.org/en/latest/specifications/depend...
        IshKebab 1y ago
        > then you don't get to use the new features in 0.5.0.
        lucky_cloud 1y ago
        Yes you do package1>=0.4.0 means 0.4.0, 0.4.1, 0.4.100, 0.4.100.1 and so on package1>=0.4 includes the above plus 0.5.0, 0.5.1, 0.6.0, 0.100.0 and so on
  - gschizas 1y ago
    I think what you want is `uv sync --upgrade`
  - petters 1y ago
    You are writing your project file incorrectly. It's not a lock file
    - incognito124 1y ago
      I never, ever, write my project file[1]. uv {add,remove} is all I ever use. [1]: I do sometimes write the title or the description. But never the deps themselves
      - wtallis 1y ago
        Even using `uv add`, you don't have to limit yourself to declaring exact versions when your intention is to allow newer versions.
      - pests 1y ago
        You can specify bounds when using uv add: uv add example>=0.4.0 Then it will update as you are thinking.
      - petters 1y ago
        Whichever method you use, you need to produce a different file that better reflects your intentions
  - hxtk 1y ago
    If you specify your constraints in pyproject.toml like this: `package1==0.4.0`; then that is the latest (and only) version satisfying your constraints. Not upgrading is expected behavior, because upgrading would violate constraints. pyproject.toml’s dependency list specifies compatibility: we expect the program to run with versions that satisfy constraints. If you want to specify an exact version as a validated configuration for a reproducible build with guaranteed functionality, well, that’s what the lock file is for. In serious projects, I usually write that dependency section by hand so that I can specify the constraints that match my needs (e.g., what is the earliest version receiving security patches or the earliest version with the functionality I need?). In unserious projects, I’ll leave the constraints off entirely until a breakage is discovered in practice. If `uv` is adding things with `==` constraints, that’s why upgrades are not occurring, but the solution is to relax the constraints to indicate where you are okay with upgrades happening.
    - incognito124 1y ago
      > ... the solution is to relax the constraints to indicate where you are okay with upgrades happening. Yeah, that's pretty much what I've been doing with my workaround script. And btw most of my projects are deeply unserious, and I do understand why one should not do that in any other scenario. Still, I dream of `uv refresh` :D
      - collinmanderson 1y ago
        There's an open issue for "Upgrade dependencies in pyproject.toml (uv upgrade)": https://github.com/astral-sh/uv/issues/6794 https://github.com/astral-sh/uv/issues/6794
ketozhang 1y ago
You could either delete the .venv and recreate it or run `uv pip install --upgrade .` Much prefer not thinking about venvs.
- incognito124 1y ago
  Actually, it won't work. I tried it and running `uv run script.py` just reinstalls the deps back... which is, I admit, the behaviour I expect and want as a user.
deleted 1y ago
[deleted]
Cogito 1y ago
This worked pretty well for me: uv add --dev uv-bump uv-bump Agree that something like this should be built in. https://pypi.org/project/uv-bump/ https://pypi.org/project/uv-bump/

jmtulloss 1y ago

Does `uv lock —upgrade` not do what you want?

incognito124 1y ago
Unfortunately, no. Only `uv.lock` gets updated, but the dependencies in `pyproject.toml` are frozen at their original constraints. What I want is, if my project depends on `package1==0.4.0` and there are new versions of package1, for uv to try install the newer version. and to do that for a) all the deps, simultaneously, b) without me explicitly stating the dependencies in the command line since they're already written in the pyproject.toml. an `uv refresh` of sorts
- wtallis 1y ago
  > What I want is, if my project depends on `package1==0.4.0` and there are new version of package1, for uv to try install the newer version. I think you're just specifying your dependency constraints wrong. What you're asking for is not what the `==` operator is for; you probably want `~=`.
- Eridrus 1y ago
  Why not depend on package1>=0.4.0 rather than specifying an explicit version? Then uv will upgrade it to the latest version. pyproject.toml is meant to encode the actual constraints for when your app will function correctly, not hardcode exact versions, which is what the lockfile is for.
  - IshKebab 1y ago
    Because then you don't get to use the new features in 0.5.0. Though I do think with Python in particular it's probably better to manually upgrade when needed, rather than opportunistically require the latest, because Python can't handle two versions of the same package in one venv.
    - lucky_cloud 1y ago
      Then make your dependency package1>=0.4 https://packaging.python.org/en/latest/specifications/dependency-specifiers/#dependency-specifiers https://packaging.python.org/en/latest/specifications/depend...
      - IshKebab 1y ago
        > then you don't get to use the new features in 0.5.0.
        lucky_cloud 1y ago
        Yes you do package1>=0.4.0 means 0.4.0, 0.4.1, 0.4.100, 0.4.100.1 and so on package1>=0.4 includes the above plus 0.5.0, 0.5.1, 0.6.0, 0.100.0 and so on
- gschizas 1y ago
  I think what you want is `uv sync --upgrade`
- petters 1y ago
  You are writing your project file incorrectly. It's not a lock file
  - incognito124 1y ago
    I never, ever, write my project file[1]. uv {add,remove} is all I ever use. [1]: I do sometimes write the title or the description. But never the deps themselves
    - wtallis 1y ago
      Even using `uv add`, you don't have to limit yourself to declaring exact versions when your intention is to allow newer versions.
    - pests 1y ago
      You can specify bounds when using uv add: uv add example>=0.4.0 Then it will update as you are thinking.
    - petters 1y ago
      Whichever method you use, you need to produce a different file that better reflects your intentions
- hxtk 1y ago
  If you specify your constraints in pyproject.toml like this: `package1==0.4.0`; then that is the latest (and only) version satisfying your constraints. Not upgrading is expected behavior, because upgrading would violate constraints. pyproject.toml’s dependency list specifies compatibility: we expect the program to run with versions that satisfy constraints. If you want to specify an exact version as a validated configuration for a reproducible build with guaranteed functionality, well, that’s what the lock file is for. In serious projects, I usually write that dependency section by hand so that I can specify the constraints that match my needs (e.g., what is the earliest version receiving security patches or the earliest version with the functionality I need?). In unserious projects, I’ll leave the constraints off entirely until a breakage is discovered in practice. If `uv` is adding things with `==` constraints, that’s why upgrades are not occurring, but the solution is to relax the constraints to indicate where you are okay with upgrades happening.
  - incognito124 1y ago
    > ... the solution is to relax the constraints to indicate where you are okay with upgrades happening. Yeah, that's pretty much what I've been doing with my workaround script. And btw most of my projects are deeply unserious, and I do understand why one should not do that in any other scenario. Still, I dream of `uv refresh` :D
    - collinmanderson 1y ago
      There's an open issue for "Upgrade dependencies in pyproject.toml (uv upgrade)": https://github.com/astral-sh/uv/issues/6794 https://github.com/astral-sh/uv/issues/6794

ketozhang 1y ago

You could either delete the .venv and recreate it or run `uv pip install --upgrade .` Much prefer not thinking about venvs.

incognito124 1y ago
Actually, it won't work. I tried it and running `uv run script.py` just reinstalls the deps back... which is, I admit, the behaviour I expect and want as a user.

deleted 1y ago

[deleted]

Cogito 1y ago

This worked pretty well for me: uv add --dev uv-bump uv-bump Agree that something like this should be built in. https://pypi.org/project/uv-bump/ https://pypi.org/project/uv-bump/