-
-
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
Stabilise nix hash
and subcommands
#8876
Comments
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-08-28-nix-team-meeting-minutes-83/32290/1 |
This should also align with a builtin. Such a builtin has been proposed, |
A comment in #4354 suggested we rename our base32 to avoid confusion. I missed that before but now support it — docs aren't good enough. The new CLI is the perfect time to introduce the name change, since the choice of base is really CLI thing (the language and various file and wire formats do not contain the names of base to my knowledge). |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-09-25-nix-team-meeting-minutes-89/33489/1 |
I am not passionate either way except that we should not break existing code and continue accepting Has this been decided on by https://github.com/orgs/NixOS/teams/nix-team? |
Currently, this is how the internal hash conversion support looks like: struct Hash { // ...
static Hash parseAny(std::string_view s, std::optional<HashType> type);
// ...
} In your proposal, you suggest making The current code does the following:
I think that this is reasonable. It disallows auto-detection of different formats that result in the same length. But even if we introduce new formats resulting in the same length (e.g. alternative base32 encodings), we could still default to the current formats for compatibility. Therefore, I'd allow skipping For non-SRI hashes, I'd make It would be nice to get formal approval by the https://github.com/orgs/NixOS/teams/nix-team for this as well. |
I would also make Some examples with my suggestions implemented for
Tell me what you think! |
This deviated from the proposal! See comments on the issue. NixOS#8876
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-11-27-nix-team-meeting-minutes-107/36112/1 |
This deviated from the proposal! See comments on the issue. NixOS#8876
To be consistent with CLI, nix API and many other references. As part of this, we also converted it to a scoped enum. NixOS#8876
To be consistent with CLI, nix API and many other references. As part of this, we also converted it to a scoped enum. NixOS#8876
...and also adjusted parsing accordingly. Also added CLI completion for HashFormats. NixOS#8876
(But not yet nix-hash since `nix hash` is still hidden behind a feature flag.) NixOS#8876
This deviated from the proposal! See comments on the issue. NixOS#8876
To be consistent with CLI, nix API and many other references. As part of this, we also converted it to a scoped enum. NixOS#8876
...and also adjusted parsing accordingly. Also added CLI completion for HashFormats. NixOS#8876
(But not yet nix-hash since `nix hash` is still hidden behind a feature flag.) NixOS#8876
"warning: you don'\''t have Internet access; disabling some network-dependent features" ... NixOS#8876
We now have |
For the onlookers / those otherwise interested in helping out, could you say more about what EDIT: I was under the assumption that |
I think |
the |
You could edit the issue text to indicate that |
On the flip side, on could argue that In any event, #9815 is a draft PR for the rest of this, whatever we decide. |
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
#10021 is a backwards-compatible addition, let's not be blocked on it |
Yes #10021 is extending |
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of NixOS#8876 Co-authored-by: Eelco Dolstra <[email protected]>
This implements NixOS/rfcs#136. This issue is agreed-upon by the https://github.com/orgs/NixOS/teams/nix-team.
Only leave these two commands, collapsing the existing ones into them:
nix hash convert
the current implementation makes
--from
optional, but we are not quite sure how that works. If it doesn't seem robust, we can make it mandatory instead.--algo
is optional but will error if it can't infer from SRI or guessnix hash path
:algo
is mandatory, any default would be arbitrarynar
(serialise the directory as a NAR and hash that),flat
(single file, error on directory),git
(directory, according to RFC 133)The text was updated successfully, but these errors were encountered: