This is our first breaking release since March. We’re happy to answer any questions folks have about it.
brcmthrowaway•29m ago
Can you stop the --break-system-packages madness?
woodruffw•21m ago
WDYM by madness? I know what the flag is (and what it does), but people have strong opinions in opposite directions about what Python packaging should do around system environments.
zanie•18m ago
I think we're doing what we should making isolated environments easy to use. I don't think we should take options away from people that need them.
hallvard•28m ago
Why (keep) the `uv pip` interface?
woodruffw•23m ago
It’s widely used, and there are still a lot of workflows that we hear about from users where they want/need to manually twiddle environments rather than having the “declarative” layer do it for them.
zanie•20m ago
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.
hallvard•15m ago
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.
nvme0n1p1•5m ago
Laudable goals. Have you considered gating imperative commands between a setting, maybe `tool.uv.pip.unreproducible = true` or somesuch, to gently guide people towards better workflows? You do already do something similar with `tool.uv.pip.break-system-packages`.
walthamstow•7m ago
uv pip is a brilliant adoption gateway, you get all of the speed gains for a 3 char change
Lucasoato•27m ago
Has anything changed in your day by day work since OpenAI acquisition?
woodruffw•21m ago
For me, honestly not much.
_diyar•18m ago
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.
zanie•12m ago
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 area in the near future!
Follow up: has anyone suggested the projects collaborate or eventually converge?
zanie•6m ago
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.
fishgoesblub•8m ago
Bit surprised, and disappointed to not see dynamic field support for the uv build backend, need it for dynamically getting the version from Git. Is there anything blocking it, or is it just not important enough?
zanie•5m ago
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.
yablak•18m ago
thoughts on worm safety w.r.t. `exclude-newer`, and the right way to handle unpinned git repo deps?
woodruffw•34m ago
brcmthrowaway•29m ago
woodruffw•21m ago
zanie•18m ago
hallvard•28m ago
woodruffw•23m ago
zanie•20m ago
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.
hallvard•15m ago
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.
nvme0n1p1•5m ago
walthamstow•7m ago
Lucasoato•27m ago
woodruffw•21m ago
_diyar•18m ago
zanie•12m ago
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 area in the near future!
[1] https://peps.python.org/pep-0817/ [2] https://peps.python.org/pep-0825/ [3] https://docs.astral.sh/uv/guides/integration/pytorch/#automa...
helltone•13m ago
Follow up: has anyone suggested the projects collaborate or eventually converge?
zanie•6m ago
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.
fishgoesblub•8m ago
zanie•5m ago