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_package shouldn't default to <nixpkgs> #24

Closed
guibou opened this issue Aug 7, 2018 · 1 comment · Fixed by #25
Closed

nixpkgs_package shouldn't default to <nixpkgs> #24

guibou opened this issue Aug 7, 2018 · 1 comment · Fixed by #25

Comments

@guibou
Copy link
Contributor

guibou commented Aug 7, 2018

When calling nixpkgs_package without any of the path or repository argument, bazel complains:

DEBUG: /home/guillaume/.cache/bazel/_bazel_guillaume/9923957c70cd7b59bec21e32af97c8be/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl:66:5: 
WARNING: Implicitly using '<nixpkgs>' as the location of Nixpkgs.
This is not recommended because it makes the build non-hermetic.
Set which Nixpkgs to use explicitly using 'repository' or 'path' attributes.

My setup is correct and hermetic because the file pointed by nix_file setups its own pinned clone of nixpkgs. To remove the warning, I have to set a dummy path = ".".

I propose the following changes:

  • remove the defaulting to <nixpkgs> when neither path nor repository are selected. and instead load the provided nix_file (or nix_file_content) with no value for <nixpkgs>.
  • (optional) add a new attribute enable_impure_nixpkgs_source, with default to false, which re-enable the current behavior.

This way, by default, the user MUST provides either path or repository or a nix_file with a pinned nixpkgs. The optional new attribute may allow her to get back the unsafe behavior.

I'm opening the issue for discussion, PR will follow if we agree on the design.

This may be a good final conclusion to #17

@mboes
Copy link
Member

mboes commented Aug 8, 2018

  • remove the defaulting to when neither path nor repository are selected. and instead load the provided nix_file (or nix_file_content) with no value for .

OK.

  • (optional) add a new attribute enable_impure_nixpkgs_source, with default to false, which re-enable the current behavior.

Let's not do this. Defaulting <nixpkgs> was a misfeature, as argued in #17.

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 a pull request may close this issue.

2 participants