-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pixi global list
and pixi global remove
commands
#318
Conversation
Hey @cjfuller, thanks alot for contributing, it looks good to me. Just had a few small nits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this contribution!
I see some room for improvement with regards to the architecture. Specifically I think it would be good to split the different responsibilities of finding the executables, creating executables scripts and writing those to disk. That will make them easier to reuse without requiring dryrunning.
Sorry for the delay! (Didn't have much spare time during the work week this week.) Should be ready for another look. I did the split, though along slightly different lines than you suggested. There's now one part that does the path construction and mapping from the binaries in the environment to the globally installed binaries, and another that builds the script content and writes it to the global binary location. (We only needed the path part for remove/list, not the actual content, so I just split out the shared parts.) |
This looks great now @cjfuller ! I'm just waiting for CI and then I'll merge. Thank you! |
This fixes #314 and #50 by adding two new global commands
global list
andglobal remove
for inspecting and removing the globally installed packages.In order to avoid having to try to map back the installed binaries to their source packages via parsing the shell scripts or something, the general approach I took here was to add a dry run option to the function that generates the binary scripts, such that we can re-run the script generation on list or remove to see what files would be generated for a given package and thus belong to that package. (This strategy has at least two small flaws: it's not very backwards compatible if pixi decides to change the names of the generated files at some point, and it's not robust to two different packages installing a binary with the same name. The former could perhaps be fixed later by writing some kind of manifest into the env instead that persists the list of generates files? The latter could be fixed by refusing to install two binaries with the same name at install time?)
I didn't see a test harness that can run automated tests of the
global
commands, so I tested manually using the following steps. (Happy to go back and add automated tests if there is such a harness and I just missed it.)Manual test steps: