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

Introduce a data attribute to nixpkgs_package #18

Merged
merged 3 commits into from
Jun 17, 2018

Conversation

guibou
Copy link
Contributor

@guibou guibou commented Jun 13, 2018

This is a solution for #17, the new data attribute references all the files
needed to execute the nix expression, hence invalidating cache if they are
modified.

mboes
mboes previously requested changes Jun 14, 2018
Copy link
Member

@mboes mboes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extra sources files are not really data. They're extra source files. While #17 seems to claim a more general problem, AFAICS this is just a classic problem of a) not declaring all the inputs properly, b) not being able to. If we make nix_file a list attribute instead of a label attribute, then we can provide as many *.nix source files as we want. If Nixpkgs itself changes, then that will be captured by a change in the definition of nixpkgs_repository.

So in short, I think this is the right thing to do. But a spec by example should be closer to:

nixpkgs_package(
  name = "foo",
  srcs = glob(["*.nix"]),
  attribute_path = "foo",
  repository = "@nixpkgs",
)

@guibou
Copy link
Contributor Author

guibou commented Jun 14, 2018

@mboes the point of using data was that the "root" nix file was specified in nix_file and all the dependencies are in data. I can rename it srcs if you wish.

But what about nix_file, should we keep it or delete it? If we remove it, which file in srcs should be used? The order is not reliable because user may use glob to fill srcs. Should we use srcs AND nix_file?

@Fuuzetsu
Copy link
Collaborator

@mboes I don't think the issue is only up to nix files and data was a better name. The nix file itself can refer to arbitrary files: if the arbitrary file changes and the nix file doesn't, currently bazel will not re-run the role. I thought this was the original problem. Of course these arbitrary files could be other nix files but that's only a subset of possible inputs.

@guibou guibou dismissed mboes’s stale review June 16, 2018 14:41

Complains addressed

@guibou
Copy link
Contributor Author

guibou commented Jun 16, 2018

@mboes name changed from data to srcs. And one of repository or path attribute should be setup.

guibou and others added 3 commits June 17, 2018 13:48
This is a solution for #17, the new attribute references all the files
needed to execute the nix expression, so that the cache can properly
be invalidated if they change.
ctx.path(filename) is ineffective in introducing an explicit
dependency of the repository rule on filename. Use symlinks instead.
Previously, it was needlessly depending on the network, and depending
on large files downloaded from the network.
@mboes mboes force-pushed the gb/cache_nixpkgs_package branch from 65b3bac to f028a8b Compare June 17, 2018 12:16
@mboes
Copy link
Member

mboes commented Jun 17, 2018

@Fuuzetsu data is typically used for runtime dependencies. But there is no "runtime" here, and these are dependencies of the package metadata description. Technically the build_file could also have dependencies, since it can load(). So opting for renaming to nix_file_deps.

@mboes mboes merged commit 7e455ad into master Jun 17, 2018
@mboes mboes deleted the gb/cache_nixpkgs_package branch June 17, 2018 12:19
@aherrmann aherrmann mentioned this pull request Jul 18, 2023
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants