| ▲ | hallvard a day ago |
| Why (keep) the `uv pip` interface? |
|
| ▲ | zanie a day ago | parent | next [-] |
| 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 a day ago | parent | next [-] | | 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 a day ago | parent | next [-] | | 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 a day ago | parent | prev [-] | | 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 a day ago | parent [-] | | Perhaps something requiring opt-in sooner, so project maintainers can - through config - say "we don't use the pip interface on this project"? |
|
| |
| ▲ | hallvard a day ago | parent | prev [-] | | 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 a day ago | parent [-] | | 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 a day ago | parent | prev | next [-] |
| 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 a day ago | parent | prev | next [-] |
| 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 a day ago | parent | prev [-] |
| uv pip is a brilliant adoption gateway, you get all of the speed gains for a 3 char change |
| |
| ▲ | ethin a day ago | parent | next [-] | | 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 a day ago | parent | prev [-] | | Yeah, I don't think I'd have made the jump otherwise, since convincing others on the team would have been much harder. | | |
|
