5 ms·

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 compat

by zanie 2mo 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 2mo 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 2mo 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.
nvme0n1p1 2mo 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`.
- zanie 2mo 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 2mo ago
    Perhaps something requiring opt-in sooner, so project maintainers can - through config - say "we don't use the pip interface on this project"?
- notatallshaw 2mo 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.

by zanie 2mo ago

hallvard 2mo 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 2mo 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.

nvme0n1p1 2mo 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`.

zanie 2mo 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 2mo ago
  Perhaps something requiring opt-in sooner, so project maintainers can - through config - say "we don't use the pip interface on this project"?
notatallshaw 2mo 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.