Skip to content

Conversation

@weswc
Copy link
Member

@weswc weswc commented Nov 14, 2025

Adding the flag --ignore-library (up for renaming if desired) to sync, add, upgrade, plan, and summary to behave as if there is no library present.

The main motivation was to provide a way to list the full dependency resolution of the config, not just the diff. Including it for the other commands that consider the library state was simply a bonus.

For sync commands, this removes all deps in the library and replaces them with the staging (similar to earlier versions). This may not be ideal on NFS systems, but this flag would most often be used in those scenarios when the goal is to get rid of something in the library.

Note, this was initially done using CC, but after a couple iterations (which I need to do better at committing) it was trying to overcomplicate this and make separate pathways to handle this, so this change was primarily "hand" written.

@weswc weswc requested a review from Keats November 14, 2025 16:33
@Keats
Copy link
Collaborator

Keats commented Nov 18, 2025

For sync commands, this removes all deps in the library and replaces them with the staging (similar to earlier versions). This may not be ideal on NFS systems, but this flag would most often be used in those scenarios when the goal is to get rid of something in the library.

Wouldn't that happen in a normal sync? I don't really get the point of --ignore-library. When would it be useful in practice?

The main motivation was to provide a way to list the full dependency resolution of the config

Isn't that rv sync + rv tree?

@weswc
Copy link
Member Author

weswc commented Nov 18, 2025

The only scenario I can think of but if a project installs from binary repo, then a different project compiles from source with some compilation flags. With the incremental install, there's no good way to get that new compilation into the project. The other scenario may be local to me, but when testing and/or building packages from PRISM, I want to make sure I'm doing a completely new install, so end up removing the library and lockfile, so I could instead do rv upgrade --ignore-library.

For the second part, rv tree is too verbose for some scenarios. When I'm helping to debug for scientists in merge conflicts and such, I simply want to see all of the deps and where they'd come from. I don't care about what's installed in their library or what they are a dependency of, I simply want to see the complete dependency burden with each pkg only listed once.

Ultimately, I'm okay with dropping the sync --ignore-library if we think there is a better incantation for seeing a list of the "dependency burden"

@dpastoor
Copy link
Member

Ultimately, I'm okay with dropping the sync --ignore-library if we think there is a better incantation for seeing a list of the "dependency burden"

yeah this feels like a loaded library - i would much rather have a clearer flag for sync like rv sync --overwrite or --clear-library

I also agree that this type of ability to push through failure/resolution problems to get access to information in certain situations we need to resolve, but i think we can do better at the 'source' - eg rv plan should never fail for things like a lock on a package. It might warn you that if you synced right then there could be issues, but it should give data back. Same thing as summary etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants