Skip to content
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

Feature request: Help diagnose packages with file collisions #29

Open
exarkun opened this issue Jan 28, 2022 · 2 comments
Open

Feature request: Help diagnose packages with file collisions #29

exarkun opened this issue Jan 28, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@exarkun
Copy link

exarkun commented Jan 28, 2022

Thanks for nix-tree! It's great. I love these tools that take advantage of all the great information available from the Nix packaging system.

One thing I'd really like to use nix-tree for is to help better understand file collisions (in particular, when building Python environments).

From time to time I accidentally build a Python environment that includes two derivations of the same Python package. Sometimes this is because two upstream versions of the Python package are being included but more often the upstream version is the same and something about the Nix derivation has changed (eg, versions of dependencies).

If I use nix-tree to inspect this situation then I don't learn much because nix-tree convenient chops off the output hash portion of the store object name. Thus, I see that my Python environment includes "python3.7-autobahn-21.3.1.drv" and "python3.7-autobahn-21.3.1.drv".

It would be great if I could tell these apart in nix-tree. Perhaps if nix-tree notices there are duplicates after constructing the short versions of the names, it could append the minimum hash prefix necessary to disambiguate? For example, if one python3.7-autobahn-21.3.1.drv has an output path of /nix/store/z7zhlhp2jqiza7kwa3kdbw7vvd918gyz-python3.7-autobahn-21.3.1 and the other has an output path of /nix/store/z86hmnd5hiyqy4y2p96macy2v6qz84bn-python3.7-autobahn-21.3.1 then they could be displayed in nix-tree as "python3.7-autobahn-21.3.1.drv (z7)" and "python3.7-autobahn-21.3.1.drv (z8)".

@exarkun
Copy link
Author

exarkun commented Jan 28, 2022

I realized I mixed up output hashes and derivation hashes in my suggestion about. I'm not sure which would be more useful, really, but I guess using the derivation hash rather than the output hash would probably be less surprising.

@utdemir
Copy link
Owner

utdemir commented Jan 28, 2022

Hey, thank you!

Perhaps if nix-tree notices there are duplicates after constructing the short versions of the names, it could append the minimum hash prefix necessary to disambiguate?

This sounds like a great idea to me! It indeed sounds confusing if there're two items in the list with the same name without a way to distinguish them. This should be a relatively easy change, the hardest part probably would be to decide on how to show them in a clear way (python3.7-autobahn-21.3.1.drv (z8) or ...84bn-python3.7-autobahn-21.3.1.drv or some other way).

I guess using the derivation hash rather than the output hash would probably be less surprising.

I think it would be a bit confusing if the hash prefix does not correspond to the exact store path selected. eg. if the store path shown is an output, that should be the path of the output hash; if it is a drv file it should be the derivation hash. I even think even it would be hard to implement it in any other way, as sometimes we do not know the derivation path from an output path or vice versa.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants