Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv 0.12.0

github.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Uv 0.12.0

#21

Post by zanie »

helltone wrote: post #16
woodruffw wrote: post #2

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

How do you think of uv vs pixi? Follow up: has anyone suggested the projects collaborate or eventually converge?

Pixi is very focused on the Conda ecosystem and implements a sort of bridge across the Conda and PyPI ecosystems. I am very interested in solving the problems that motivated creation of the Conda ecosystem, but I want to do so by driving forward the PyPI ecosystem so those use-cases can be addressed in _many_ tools instead of just one. This is the main reason you don't see us pursuing Conda package support in uv directly (in the style of Pixi).

There have been several threads about us collaborating or converging, but there are no concrete plans to do so at this time. We share some Rust crates, e.g., Pixi uses our internals to solve the PyPI-side of their dependencies, and we occasionally fix or change things for each other.

Re: Uv 0.12.0

#22

Post by nvme0n1p1 »

zanie wrote: post #10
hallvard wrote: post #5

Earlier quoted context omitted.

Why (keep) the `uv pip` interface?

We have the interface because we care a lot about meeting people where they are. We keep the interface because we care a lot about long-term support and compatibility. I cannot imagine removing it. We generally want to add features to the top-level interface such that people don't need or want to use the pip-interface because the top-level interface does everything you need, but better.

Laudable goals. Have you considered gating imperative commands behind a setting, maybe `tool.uv.pip.unreproducible = true` or somesuch? This would gently guide people towards better workflows, and also be a starting point for documenting the drawbacks of `uv pip` since it's a setting they'd be forced to add and presumably they'll read the docs for it first.

uv already does something similar with `tool.uv.pip.break-system-packages`.

Re: Uv 0.12.0

#24

Post by zanie »

fishgoesblub wrote: post #18
woodruffw wrote: post #2

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

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.

Re: Uv 0.12.0

#26

Post by fishgoesblub »

zanie wrote: post #24
fishgoesblub wrote: post #18

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.

Interesting, a better way of doing versioning would be nice. The tool I use requires a git repo setup with at least 1 commit, annoying for brand new projects. I'll be eagerly waiting to see it eventually.

Re: Uv 0.12.0

#27

Post by zanie »

nvme0n1p1 wrote: post #22
zanie wrote: post #10

Earlier quoted context omitted.

We have the interface because we care a lot about meeting people where they are. We keep the interface because we care a lot about long-term support and compatibility. I cannot imagine removing it. We generally want to add features to the top-level interface such that people don't need or want to use the pip-interface because the top-level interface does everything you need, but better.

Laudable goals. Have you considered gating imperative commands behind a setting, maybe `tool.uv.pip.unreproducible = true` or somesuch? This would gently guide people towards better workflows, and also be a starting point for documenting the drawbacks of `uv pip` since it's a setting they'd be forced to add and presumably they'll read the docs for it first. uv already does something similar with `tool.uv.pip.break-sy…

I hadn't considered that, it's an interesting idea. We generally hold a very high bar for nagging users or gating behaviors. It's possible we'll reach a point someday where this is appropriate! I think you're right that we need to teach people better workflows, but that's happening organically as use of the tool grows and people's first exposure to a Python project is `uv init` and `uv add` rather than `pip`.

Re: Uv 0.12.0

#28

Post by zanie »

hallvard wrote: post #14
zanie wrote: post #10

Earlier quoted context omitted.

We have the interface because we care a lot about meeting people where they are. We keep the interface because we care a lot about long-term support and compatibility. I cannot imagine removing it. We generally want to add features to the top-level interface such that people don't need or want to use the pip-interface because the top-level interface does everything you need, but better.

Fair points; the reason for asking is that it seems counterintuitive from the outside perspective for you to maintain/extend the pip interface as well? And of course that some colleagues of mine insist on using `uv pip` for anything and everything, which feels wrong… Granted it’s a great feature which made the transition to uv smooth in the first place.

So far the maintenance burden has been quite bearable and extending pip provides us with an opportunity to explore and encourage improvements upstream which are still beneficial to a lot of people.

Re: Uv 0.12.0

#29

Post by notatallshaw »

nvme0n1p1 wrote: post #22
zanie wrote: post #10

Earlier quoted context omitted.

We have the interface because we care a lot about meeting people where they are. We keep the interface because we care a lot about long-term support and compatibility. I cannot imagine removing it. We generally want to add features to the top-level interface such that people don't need or want to use the pip-interface because the top-level interface does everything you need, but better.

Laudable goals. Have you considered gating imperative commands behind a setting, maybe `tool.uv.pip.unreproducible = true` or somesuch? This would gently guide people towards better workflows, and also be a starting point for documenting the drawbacks of `uv pip` since it's a setting they'd be forced to add and presumably they'll read the docs for it first. uv already does something similar with `tool.uv.pip.break-sy…

FWIW, break-system-packages comes directly from pip's interface, it's not a novel addition from uv.

If Astral/OpenAI are willing to support uv pip in the long term, why do you think they should use a stick as well as a carrot to get people on uv's top level interface?

While uv's standard workflows probably works for 80+% of people, at least if they learn them, I certain do a lot of stuff with uv pip and pip that can't be replicated.

Also both uv pip and pip support installing from pylock.toml files, which are fully reproducible.

Re: Uv 0.12.0

#30

Post by simonw »

woodruffw wrote: post #2

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

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

Post reply on HN