[zanie]

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]

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]

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]

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]

Perhaps something requiring opt-in sooner, so project maintainers can - through config - say "we don't use the pip interface on this project"?

[hallvard]

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]

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.