Live data from Hacker News

Uv 0.12.0

github.com

41–50 of 51 posts

Re: Uv 0.12.0

#41
post #36

Are we likely to get an "uv upgrade" command that makes sense sometime? It's still very obtuse how to get uv to just try and make all my dependencies the highest version possible.

Yes! It's in progress — it's already there, just hidden as we iterate on it.

(but as a note, the initial `uv lock` will already attempt to choose the highest possible versions and `uv lock --upgrade` will do so again, requests for `uv upgrade` are generally centered around changing the constraints in the `pyproject.toml`)

Re: Uv 0.12.0

#42

Earlier quoted context omitted.

uv pip is a brilliant adoption gateway, you get all of the speed gains for a 3 char change

Yeah, I don't think I'd have made the jump otherwise, since convincing others on the team would have been much harder.

Yes omg keep uv pip please

Re: Uv 0.12.0

#43
post #5

Earlier quoted context omitted.

Why (keep) the `uv pip` interface?

uv pip is a brilliant adoption gateway, you get all of the speed gains for a 3 char change

Agreed, I'd prefer it stick around for the long-term because I use it when creating temporary venvs to screw around with things that I'm not certain about committing to in my actual projects for example. I guess I could do that with scripts but it's nicer/easier to use uv pip

Re: Uv 0.12.0

#44
post #24

Earlier quoted context omitted.

Bit surprised, and disappointed to not see dynamic field support for the uv build backend in this update. Need it for dynamically getting the version from Git. Is there anything blocking it, or is it just not important enough?

Unfortunately dynamic metadata is not efficient for package resolution, so we don't want to encourage it. Instead, we want to design a better workflow for using source control for versioning, but haven't had the time to do so.

At what point is that the case? When a package is built, it's version is determined at that moment from whatever dynamic source, and is then written into the metadata in a static way (or surely could be if for some weird reason it isn't).

Re: Uv 0.12.0

#45
post #17
post #13

Earlier quoted context omitted.

Maybe a naive question, but any goal / progress towards an ”it just works” cuda installation? Currently, the only times i feel like i‘m stumbling over an install with uv is when pytorch / cuda is involved.

Yes! We've been working on this for quite some time as it's one of the worst experiences in Python packaging today. There are two PEPs that we're involved with that will provide the components for the ecosystem to properly declare metadata in this domain [1] [2]. We're also working on some features in uv, such as the torch backend option [3], to improve the situation in the interim. We'll be announcing more in this a…

[dead]

Re: Uv 0.12.0

#47

This is our first breaking release since March. We’re happy to answer any questions folks have about it.

Do you have any plans to support pip download?

Related, offline/air-gapped support, which is what prevents me from using it.

Re: Uv 0.12.0

#48
post #32
post #30

Earlier quoted context omitted.

The thing where "uv init" now adds this to pyproject.toml is a bit surprising: [project.scripts] demo-latest = "demo_latest:main" What's the rationale for that? My expectation is that few projects would need it. (I have a GitHub repo that captures differences between uv versions, here's today's upgrade: https://github.com/simonw/uv-init-demos/commit/9111a2bb85741... )

It makes `uv run ` work by default, I expect most projects to need an entry point.

Nah. I just put a regular `main.py` with some

  if __name__ == "__main__":
      ...
in my src/ folder. Done.

Re: Uv 0.12.0

#49
post #41
post #36

Are we likely to get an "uv upgrade" command that makes sense sometime? It's still very obtuse how to get uv to just try and make all my dependencies the highest version possible.

Yes! It's in progress — it's already there, just hidden as we iterate on it. (but as a note, the initial `uv lock` will already attempt to choose the highest possible versions and `uv lock --upgrade` will do so again, requests for `uv upgrade` are generally centered around changing the constraints in the `pyproject.toml`)

Yeah the constraints in pyproject is exactly the issue I'm thinking of.
Post reply on HN