uv pip sync should maybe have a --no-remove flag?

[thejcannon]

👋 Howdy!

At $work we use a global lockfile to manage dependencies, so uv pip sync naturally is a great fit for keeping the transient environment up-to-date with regard to the lockfile as we travel forward and backwards in time (via git ops).

However, we also support people installing certain dependencies for one-off tooling or prototyping and I'd hate to tell them to run uv pip sync and those deps dissapear.

I understand that havign some kind of --no-remove flag is likely not truly what we want (because the env will maybe become bloated over time, or maybe there's conflicting deps, or maybe we're leaving a dep with a security concern) but I think it handles the use-case well-enough that it's worth trying out.

[zanieb]

What if we have other ways to managing one-off tooling and prototyping? e.g. uv tool (#3560) or uv run --with <one-off-package>?

[thejcannon]

I expected this answer 😄 I'd love to see those. I'm not 100% certain I'd be able to convince all of the folks I support (some of which aren't engineers, and don't know what uv is, or that it's used under the hood for our common tooling) to always use the totally-awesome-uv-thing.

[charliermarsh]

I think pip install --no-deps will... basically do what you want? Internally it's like, exactly this.

[zanieb]

We'll probably expose something like this, it was in our original designs. I'm just curious to see how far we can get without exposing it by, e.g., building better APIs and want to learn more about the stories behind it. Centrally managing environment state seems like a fair use case, especially if the downstream users have access to pip. You could still definitely break their environment with a sync operation though (or the sync could fail).

[charliermarsh]

To be clear, I meant uv pip install --no-deps.

[thejcannon]

Oh...... yeeeeeaaaaaaahhhh I think you're right 🤦