-
Notifications
You must be signed in to change notification settings - Fork 84
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
Fail when 'nix_file_deps' is not exhaustive #76
Conversation
I tried this out and found an instance where it failed because of a directory that was not listed in |
Good catch @aherrmann. Do you have a detailed example I can work on?. Is that a |
@guibou It's a Nix derivation that includes |
4aa2cc0
to
8772541
Compare
@aherrmann could you give it a new look? I've fixed the issue by detecting subfiles in directories. |
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.
@guibou I tested it again. The directory issue seems to be resolved. Thank you, this is great!
You need to update the repository rule *{repo_name}* and set/extend *nix_file_deps* with the following values: | ||
|
||
nix_file_deps = [ | ||
"{deps_listing}", |
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 can contain duplicates. That may be fine. Just wanted to point it out.
E.g.
".../sass/Gemfile",
".../sass/Gemfile.lock",
".../sass/Gemfile",
".../sass/Gemfile.lock",
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.
Hey, nice catch. I'll convert to set prior to display.
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.
Well, actually, there is no set by default in skylark, and just immutable depset
which may not be suitable for this kind of job.
On the other hand, I'm afraid all this list O(n)
behavior may slow down the phase.
I've changed everything to dict
with None
values.
If `nix_file_deps` does not contain all the direct and indirect dependencies of the nix package, bazel won't rebuild it if any of these file change. This patch track the dependencies by reading nix-build verbose output and fails if theses dependencies are not explicitly listed in nix_file_deps or repositories.
251a96f
to
456bb28
Compare
Yeah no, doesn’t work:
|
Where does this |
Actually, that's your nixpkgs repository. It works as expected, you must add theses files to the |
It’s running the So it the heuristics don’t work with the most minimal setup? |
I'm not sure I understand you. From my point of view, it works as expected. You must list all the dependencies of your nix process, which, in your case, are all the files listed inside |
This means you have a list of every single nixpkgs file somewhere that you update every time your nixpkgs checkout changes? That does not sound reasonable to me. The example I gave is the most minimal setup of a rules_haskell repository with rules_nixpkgs as a dependency. It’s the absolute base case that should be supported everywhere and all the time. As long as it’s broken like that, I’m afraid we have to revert the heuristics, since they obviously don’t work even for the most basic use-case. |
Sounds better than a non hermetic build. However we can fix this issue by checking for files both the I did not do that in the first version of this work because I'm not using
You can imagine a even more minimal setup such as:
Where
I do not agree. The heuristics works (as far as I know) and is doing its job correctly and brings hermeticity and reproducibility. It is however not convenient in a specific use case which appears to be the one we document. This being said, it can be fixed and we should open an issue about it. |
To check that dependencies of `nix_file_deps` are correctly declared, we copy all declared dependencies into the external repository directory. If any dependencies were missed, then nix evaluation will fail. To test that this really works, remove the ``` nix_file_deps = ["//tests:pkgname.nix"], ``` line in `@nix-file-deps-test`. I tried writing a failure test for this using Skylibs `analysistest` framework, but that doesn't seem to work for failures in external repositories. Like #76, this likewise closes #74, but in a simpler way.
To check that dependencies of `nix_file_deps` are correctly declared, we copy all declared dependencies into the external repository directory. If any dependencies were missed, then nix evaluation will fail. To test that this really works, remove the ``` nix_file_deps = ["//tests:pkgname.nix"], ``` line in `@nix-file-deps-test`. I tried writing a failure test for this using Skylibs `analysistest` framework, but that doesn't seem to work for failures in external repositories. Like #76, this likewise closes #74, but in a simpler way.
If
nix_file_deps
does not contain all the direct and indirectdependencies of the nix package, bazel won't rebuild it if any of
these file change.
This patch track the dependencies by reading nix-build verbose output
and fails if theses dependencies are not explicitly listed in
nix_file_deps or repositories.
Closes #74