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
fetchpatch doesn't notice changes to other arguments #48567
Comments
Note that the lack of error is just one example of how this can break down; the following workflow is also completely broken:
|
Found during the same problem investigation: #48569 |
This is common for every fixed-output derivation. When there is a hash, Nix doesn't build it again and thus also doesn't do anything with the modified arguments. As soon as you make a change, you indeed need to modify the hash to determine the correct hash. |
@FRidh What I don't get is why the fixed-output derivation isn't just for the downloaded patch contents. I get that there are a few things that may want to be done as pre-processing before the contents are hashed (e.g. cutting off version strings as generated by Github), but there doesn't seem to be a benefit to capture stuff like |
I agree with you that it does more than is needed. Maybe it's better to apply the other modifications with a |
See comment for details, and NixOS/nixpkgs#48567.
See comment for details, and NixOS/nixpkgs#48567.
@nh2 The point of Do you think there is a way for us to make this more explicit and less surprising? I can see only making this explicit in the manual, and would therefore suggest using this issue to track adding a sentence mentioning it to the manual. |
@Ekleog As I mentioned in #48567 (comment), the fact that the patch contents are normalised is totally fine. That isn't what I complain about in the issue description. The issue is that right now, What should we do? I think the most straightforward way is to separate the meaningful post-processing arguments, e.g. into a separate
|
Well, that's one of the points being a fixed-output derivation. You can e.g. change the URL where it fetches from or the original URL may change contents in a way that gets normalized away – all that without causing any rebuilds and still succeeding if retried. I can't see how your "straightforward" way would work, unless you specified two hashes and thus make this IMHO more difficult to maintain. EDIT: I mean, feel free to propose something better in more detail – I just can't see it. Well, I can probably imagine with intensional store, but that's a bit longer way off. |
Ah, right, that seems possible. Using hash after normalization and before other changes. I can't see a real disadvantage of that approach – at least not immediately. There will be more derivations, store files, etc. but nothing significant. |
@nh2 You can't really do that while keeping the same semantics:
Also, IMO it would be pretty counter-intuitive to have some arguments be in the fixed-output (eg. the URL) and some not be -- even more counter-intuitive than the contrary, because nix has this fixed-output / non-fixed-output distinction well-rooted. |
I don't think you can really change anything while keeping exactly the same semantics. AFAIK the main point of |
Yes, as in many places with nix, once you know what's going on it's easy, but before that you lose hours with every little trivial thing you want to do. I hope that we can bring that down as much as possible, because it's the biggest hurdle to adoption. In any case, how about the following alternative route:
|
For the sake of persistence: I suggested a change to the fixed-output mechanics on IRC which would make them more intuitive and fix the fetchpatch problem. My proposition would be to handle FO derivations just the same as regular derivations (i.e. hashing based on inputs), and then just check the output against the provided hash (but not using that hash for the That way the usual nix semantics apply: If you change an input ( The counter arguments were
(2) probably makes this infeasible :/ |
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
this is still important |
I marked this as stale due to inactivity. → More info |
still |
For the record, I was also a bit surprised by this behaviour just now when adding |
Issue description
I wrote:
After changing
includes = ["Cabal/*"];
toincludes = ["Cabal/asdfasdfasfd"];
, which should exclude all contents of the patch and trigger this error, nothing happens (it doesn't rebuild the patch).I suspect that the whole (filtered) patch output is accidentally captured by the
sha256
somehow.Technical details
nix-build (Nix) 2.0.4
The text was updated successfully, but these errors were encountered: