Hacker News Reader

Comment by nvme0n1p1 | Hacker News Reader

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`.

View on HN

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.

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`.

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

Reply on news.ycombinator.com