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

nixpkgs_local_repository dependency change doesn't invalidate nixpkgs_package #113

Closed
jcpetruzza opened this issue Mar 11, 2020 · 5 comments · Fixed by #123 or #124
Closed

nixpkgs_local_repository dependency change doesn't invalidate nixpkgs_package #113

jcpetruzza opened this issue Mar 11, 2020 · 5 comments · Fixed by #123 or #124
Assignees

Comments

@jcpetruzza
Copy link

Given a WORKSPACE with something like this:

nixpkgs_local_repository(
    name = "nixpkgs",
    nix_file = "//my/nixpkgs/default.nix",
    nix_file_deps = [ "//my/nixpkgs/something.nix"],
)

nixpkgs_package(
    name = "foo",
    attribute_path = "foo",
    repository = "@nixpkgs",
)

I'd expect that changes to my/nixpkgs/something.nix will force @foo to be rebuilt, but it seems that it doesn't and only changes to my/nixpkgs/default.nix will do. We had some reproducibility issues because of this, our workaround was to merge everything in one big file and avoid nix_file_deps.

From looking quickly through the code, the label "@nixpkgs" corresponds to @nixpkgs//:nixpkgs and this is symlinked to my/nixpkgs/default.nix, so iiuc, from the point of view of bazel, @foo only depends on that file, and not on my/nixpkgs/something.nix. I guess @nixpkgs//:nixpkgs could instead be defined to be a filegroup() containing the given nix_file and everything in nix_file_deps?

@aherrmann
Copy link
Member

Thanks for reporting this!

The following should work correctly, i.e. adding nix_file_deps to the nixpkgs_package call:

nixpkgs_package(
    name = "foo",
    attribute_path = "foo",
    repository = "@nixpkgs",
    nix_file_deps = [ "//my/nixpkgs/something.nix"],
)

As you describe, it looks like right now nix_file_deps of nixpkgs_local_repository does not affect nixpkgs_package. I'm not sure that a filegroup will work here, since we're in the context of a repository_rule. However, what may work is to create additional symlinks in nixpkgs_local_repository for nix_file_deps.

@jcpetruzza
Copy link
Author

Just to clarify, what I meant with the filegroup() is to define it in the BUILD.bazel file generated for the @nixpkgs repo, similar to what is done with, say, :bin and :lib in the external repositories created with nixpkgs_package.

I'm not sure creating more symlinks in nixpkgs_local_repository would make a difference. It is already creating templates from them and they get updated on changes.

@aherrmann
Copy link
Member

I'm not sure creating more symlinks in nixpkgs_local_repository would make a difference. It is already creating templates from them and they get updated on changes.

Oh, it is indeed. Sorry, I overlooked that.

Just to clarify, what I meant with the filegroup() is to define it in the BUILD.bazel file generated for the @nixpkgs repo, similar to what is done with, say, :bin and :lib in the external repositories created with nixpkgs_package.

I see, and nixpkgs_package would then depend on that filegroup? That might work, do you want to give it a shot and open a PR if it works?

@mboes
Copy link
Member

mboes commented Mar 30, 2020

@jcpetruzza still working on this?

@jcpetruzza
Copy link
Author

Sorry, I haven't had the time to work on this yet. If someone wants to look into it, by all means, go ahead! 🙂

@nlewo nlewo self-assigned this Apr 20, 2020
nlewo added a commit that referenced this issue Apr 20, 2020
Nix files of a nixpkgs_local_repository are not tracked by the
nixpkgs_package rule. In this commit, we generate the list of these
files in the nixpkgs_local_repository and make the nixpkgs_package
rule reading this list to add all of these files in its own repository
to let Bazel track them.

The list of files is propagated from a rule to the other one throught
a file named `nix-file-deps` created in the
`nixpkgs_local_repository` repository.

Closes #113
nlewo added a commit that referenced this issue Apr 20, 2020
Additional Nix files of a `nixpkgs_local_repository` are not tracked
by the `nixpkgs_package` rule. In this commit, we generate the list of
these files in the `nixpkgs_local_repository` rule and make the
`nixpkgs_package` rule reading this list to add all of these files in
its own repository to let Bazel track them.

The list of files is propagated from one rule to the other one
throught a file named `nix-file-deps` created in the
`nixpkgs_local_repository` repository.

Closes #113
nlewo added a commit that referenced this issue Apr 21, 2020
Additional Nix files of a `nixpkgs_local_repository` are not tracked
by the `nixpkgs_package` rule. In this commit, we generate the list of
these files in the `nixpkgs_local_repository` rule and make the
`nixpkgs_package` rule reading this list to add all of these files in
its own repository to let Bazel track them.

The list of files is propagated from one rule to the other one
throught a file named `nix-file-deps` created in the
`nixpkgs_local_repository` repository.

Closes #113
nlewo added a commit that referenced this issue Apr 21, 2020
Additional Nix files of a `nixpkgs_local_repository` are not tracked
by the `nixpkgs_package` rule. In this commit, we generate the list of
these files in the `nixpkgs_local_repository` rule and make the
`nixpkgs_package` rule reading this list to add all of these files in
its own repository to let Bazel track them.

The list of files is propagated from one rule to the other one
throught a file named `nix-file-deps` created in the
`nixpkgs_local_repository` repository.

Closes #113
mboes pushed a commit that referenced this issue Apr 22, 2020
Additional Nix files of a `nixpkgs_local_repository` are not tracked
by the `nixpkgs_package` rule. In this commit, we generate the list of
these files in the `nixpkgs_local_repository` rule and make the
`nixpkgs_package` rule reading this list to add all of these files in
its own repository to let Bazel track them.

The list of files is propagated from one rule to the other one
throught a file named `nix-file-deps` created in the
`nixpkgs_local_repository` repository.

Closes #113
@mergify mergify bot closed this as completed in #123 Apr 22, 2020
mboes added a commit that referenced this issue Apr 22, 2020
PR #123 fixed #113, but introduced a regression. The regression was
due to the label for the `nix_file_deps` files from the
`nixpkgs_local_repository` being constructed incorrectly.
nlewo added a commit that referenced this issue Apr 23, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace take into account these changes.

This is a regression test for the issue #113.
nlewo added a commit that referenced this issue Apr 23, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace takes into account these changes.

This is a regression test for the issue #113.
nlewo added a commit that referenced this issue Apr 27, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace takes into account these changes.

This is a regression test for the issue #113.
nlewo added a commit that referenced this issue Apr 28, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace takes into account these changes.

This is a regression test for the issue #113.
nlewo added a commit that referenced this issue May 13, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace takes into account these changes.

This is a regression test for the issue #113.
nlewo added a commit that referenced this issue May 13, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace takes into account these changes.

This is a regression test for the issue #113.
nlewo added a commit that referenced this issue May 18, 2020
This test runs Bazel in the Bazel sandbox to ensure some dependencies
are well tracked at the workspace level. So, we create a workspace,
build it, then change the content of some workspace files and check if
a rebuild of this workspace takes into account these changes.

This is a regression test for the issue #113.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants