-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
nix hash path
, text hashing for nix store add
, and preparatory refactors
#9815
Conversation
b7507ec
to
31bdead
Compare
31bdead
to
ed22314
Compare
Thanks @cole-h for finding in NixOS#9815 (comment)
ed22314
to
ddb5764
Compare
nix hash path
, and preperatory refactorsnix hash path
, text hasing for nix store add
, and preperatory refactors
19095bd
to
61e7690
Compare
Discussed during the Nix maintainers meeting on 2024-01-22.
- @edolstra: Is exposing `text` really good?
- @Ericson2314: If it exists, I think we should exposed it even if it has some warnings/deprecations/etc.
- @roberth: Document that it is not needed for users. Recommend that they just use `flat`. It needs to be kept around for the Nix language.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-01-22-nix-team-meeting-minutes-117/38838/1 |
61e7690
to
078b2c2
Compare
I updated the docs to make more clear that |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-01-30-nix-team-meeting-minutes-119/39185/1 |
078b2c2
to
c901988
Compare
I'm afraid this is way too many unrelated things for me to review at once. Please split that so that it's possible to make sense of the various parts |
c901988
to
205fe57
Compare
Sigh, I was hoping the comments I left would ameliorate that. I have no split off prep PRs and gotten them merged, so I hope this is small enough. |
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.
This is a mixed bag of several things, trying to split them up here:
- I don't really get the point of moving the hash arguments to
libcmd
- The addition of
text
hashing is good, although it's weird to have bothfileIngestionMethod
andcontentAddressMethod
(at least that would require some explanatory comment if there's really a reason to keep them both) - The proper split of
nix hash path
andnix hash file
is good too, with the caveat that it should be done more strictly (can be a follow-up) like giving them a proper documentation, and restrictingnix hash file
to only files
src/nix/hash.cc
Outdated
addFlag({ | ||
.longName = "sri", | ||
.description = "Print the hash in SRI format.", | ||
.handler = {&hashFormat, HashFormat::SRI}, | ||
}); | ||
|
||
addFlag({ | ||
.longName = "base64", | ||
.description = "Print the hash in base-64 format.", | ||
.handler = {&hashFormat, HashFormat::Base64}, | ||
}); | ||
|
||
addFlag({ | ||
.longName = "base32", | ||
.description = "Print the hash in base-32 (Nix-specific) format.", | ||
.handler = {&hashFormat, HashFormat::Nix32}, | ||
}); | ||
|
||
addFlag({ | ||
.longName = "base16", | ||
.description = "Print the hash in base-16 format.", | ||
.handler = {&hashFormat, HashFormat::Base16}, | ||
}); | ||
|
||
addFlag(flag::hashAlgo("type", &hashAlgo)); |
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.
If they are deprecated, I think they should be marked as such
src/nix/hash.cc
Outdated
addFlag({ | ||
.longName = "sri", | ||
.description = "Print the hash in SRI format.", | ||
.handler = {&hashFormat, HashFormat::SRI}, | ||
}); | ||
|
||
addFlag({ | ||
.longName = "base64", | ||
.description = "Print the hash in base-64 format.", | ||
.handler = {&hashFormat, HashFormat::Base64}, | ||
}); | ||
|
||
addFlag({ | ||
.longName = "base32", | ||
.description = "Print the hash in base-32 (Nix-specific) format.", | ||
.handler = {&hashFormat, HashFormat::Nix32}, | ||
}); | ||
|
||
addFlag({ | ||
.longName = "base16", | ||
.description = "Print the hash in base-16 format.", | ||
.handler = {&hashFormat, HashFormat::Base16}, | ||
}); | ||
|
||
addFlag(flag::hashAlgo("type", &hashAlgo)); |
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.
I'm not clear why these are kept for nix hash file
and not nix hash path
. Both commands accept them similarly right now, so we should either drop them for both, or (preferably) keep them for both. But keeping them for only one seems weird and inconsistent. Or am I missing something?
Just checking, did you read what I wrote in the PR description? I am happy to elaborate if it still doesn't make sense. |
17bb465
to
2642764
Compare
- `nix store add` supports text hashing With functional test ensuring it matches `builtins.toFile`. - Factored-out flags for both commands - Move all common reusable flags to `libcmd` - They are not part of the *definition* of the CLI infra, just a usag of it. - The `libstore` flag couldn't go in `args.hh` in libutil anyways, would be awkward for it to live alone - Shuffle around `Cmd*` hierarchy so flags for deprecated commands don't end up on the new ones
2642764
to
efd36b4
Compare
It makes sense, it just feels like a very heavy hammer for the small change |
@thufschmitt is #9815 (comment) satisfactory? Are there any other outstanding issues? |
Nah, looks good. Let's merge! |
Thank you!! |
Motivation
Finish #8876
Context
nix store add
supports text hashingWith functional test ensuring it matches
builtins.toFile
.Factored-out flags for both
Move all common reusable flags to
libcmd
They are not part of the definition of the CLI infra, just a usage
of it.
The new
libstore
flag couldn't go inargs.hh
inlibutil
anyways,would be awkward for it to live alone separate from the others
Shuffle around
Cmd*
hierarchy so flags for deprecated commands don't end up on the new onesPriorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.