It makes `uv run <project-name>` work by default, I expect most projects to need an entry point.
codethief 20 hours ago [-]
Nah. I just put a regular `main.py` with some
if __name__ == "__main__":
...
in my src/ folder. Done.
_diyar 1 days 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 1 days 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 1 days 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.
Lucasoato 1 days ago [-]
Has anything changed in your day by day work since OpenAI acquisition?
woodruffw 1 days ago [-]
For me, honestly not much.
hallvard 1 days ago [-]
Why (keep) the `uv pip` interface?
zanie 1 days 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.
nvme0n1p1 1 days ago [-]
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`.
notatallshaw 1 days ago [-]
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.
zanie 1 days ago [-]
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`.
EuanReid 24 hours ago [-]
Perhaps something requiring opt-in sooner, so project maintainers can - through config - say "we don't use the pip interface on this project"?
hallvard 1 days 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.
zanie 1 days ago [-]
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.
woodruffw 1 days 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.
ghshephard 24 hours ago [-]
I'll confess to using `uv` almost every day for the last year+ - and I've never used anything other than `uv pip install` for package management.
Is there any compelling reason not to?
walthamstow 1 days ago [-]
uv pip is a brilliant adoption gateway, you get all of the speed gains for a 3 char change
ethin 23 hours ago [-]
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
gkhartman 24 hours ago [-]
Yeah, I don't think I'd have made the jump otherwise, since convincing others on the team would have been much harder.
whattheheckheck 23 hours ago [-]
Yes omg keep uv pip please
fishgoesblub 1 days ago [-]
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?
zanie 1 days 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.
fishgoesblub 1 days ago [-]
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.
Induane 22 hours ago [-]
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).
simonw 1 days ago [-]
What's blocking a 1.0 release at this point?
notatallshaw 24 hours ago [-]
Or an obscure CalVer that no one realizes - /pip-maintainer
brcmthrowaway 1 days ago [-]
Can you stop the --break-system-packages madness?
woodruffw 1 days 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 1 days 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.
1 days ago [-]
carsmain 23 hours ago [-]
Do you have any plans to support pip download?
nomel 21 hours ago [-]
Related, offline/air-gapped support, which is what prevents me from using it.
21 hours ago [-]
pytorch_app4 1 days ago [-]
[flagged]
uvvuajd 1 days ago [-]
[flagged]
drzhouq 1 days ago [-]
When can uv install gdal?
yablak 1 days ago [-]
thoughts on worm safety w.r.t. `exclude-newer`, and the right way to handle unpinned git repo deps?
1 days ago [-]
drcongo 11 hours ago [-]
Still no `uv show` and still no homepage link in `uv pip show`. I love uv, but man the ux needs some work.
XorNot 24 hours ago [-]
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.
zanie 23 hours ago [-]
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`)
XorNot 20 hours ago [-]
Yeah the constraints in pyproject is exactly the issue I'm thinking of.
peterdsharpe 24 hours ago [-]
`uv sync --upgrade`? It's in the docs
analognoise 1 days ago [-]
[flagged]
Rendered at 21:02:22 GMT+0000 (Coordinated Universal Time) with Vercel.
(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...)
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...
Follow up: has anyone suggested the projects collaborate or eventually converge?
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.
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.
uv already does something similar with `tool.uv.pip.break-system-packages`.
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.
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.
Is there any compelling reason not to?
It's still very obtuse how to get uv to just try and make all my dependencies the highest version possible.
(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`)