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

New nix-specific configuration setting #121

Closed
mboes opened this issue Apr 19, 2020 · 0 comments · Fixed by #122
Closed

New nix-specific configuration setting #121

mboes opened this issue Apr 19, 2020 · 0 comments · Fixed by #122

Comments

@mboes
Copy link
Member

mboes commented Apr 19, 2020

Is your feature request related to a problem? Please describe.

Platforms use the //nixpkgs/constraints:nixpkgs constraint value to indicate that they support Nix. However, this constraint value is both poorly named and poorly designed. It's poorly named because we don't care about Nixpkgs support per se, we care about whether Nix is available on the system or not. It's poorly designed because it's a value of the @bazel_tools//tools/cpp:cc_compiler constraint setting, which is an abuse of that setting. Platforms can only set one constraint value for any given constraint setting, yet we'd want to set a C/C++ compiler constraint value independently of whether it comes from Nixpkgs or not.

Describe the solution you'd like

Define a new constraint setting, called nix, with one constraint value, called support_nix. This is the pattern used in https://github.com/bazelbuild/bazel-toolchains, e.g. for sanitizer support or Docker support.

Describe alternatives you've considered

An alternative would be to ask upstream to define a generic package_manager constraint setting, with nixpkgs being a constraint value. I ask for precisely this in bazelbuild/platforms#5. Apart from the fact that it has proved to avoid the discussion there from stalling, I think that in the end doing differently may be better anyways. Multiple package managers should be able to coexist. Defining a new constraint_setting rather than using a generic one is simpler, works for now, and there isn't much to be gained from defining a unique slot for all package tools like Flatpak, Snappy, Nix etc.

mboes added a commit that referenced this issue Apr 19, 2020
Platforms supporting Nix previously used the
`//nixpkgs/constraints:nixpkgs` constraint value. However, this
constraint value is associated to a bizarre constraint setting:
`@bazel_tools//tools/cpp:cc_compiler`. A better option is to define
a new `constraint_setting`, with a single `constraint_value`, in the
style of bazelbuild/bazel-toolchains.

Deprecates `//nixpkgs/constraints:nixpkgs`.

Closes #121
mboes added a commit that referenced this issue Apr 19, 2020
Platforms supporting Nix previously used the
`//nixpkgs/constraints:nixpkgs` constraint value. However, this
constraint value is associated to a bizarre constraint setting:
`@bazel_tools//tools/cpp:cc_compiler`. A better option is to define
a new `constraint_setting`, with a single `constraint_value`, in the
style of bazelbuild/bazel-toolchains.

Deprecates `//nixpkgs/constraints:nixpkgs`.

Closes #121
mboes added a commit that referenced this issue Apr 20, 2020
Platforms supporting Nix previously used the
`//nixpkgs/constraints:nixpkgs` constraint value. However, this
constraint value is associated to a bizarre constraint setting:
`@bazel_tools//tools/cpp:cc_compiler`. A better option is to define
a new `constraint_setting`, with a single `constraint_value`, in the
style of bazelbuild/bazel-toolchains.

Deprecates `//nixpkgs/constraints:nixpkgs`.

Closes #121
mboes added a commit that referenced this issue Apr 20, 2020
Platforms supporting Nix previously used the
`//nixpkgs/constraints:nixpkgs` constraint value. However, this
constraint value is associated to a bizarre constraint setting:
`@bazel_tools//tools/cpp:cc_compiler`. A better option is to define
a new `constraint_setting`, with a single `constraint_value`, in the
style of bazelbuild/bazel-toolchains.

Deprecates `//nixpkgs/constraints:nixpkgs`.

Closes #121
@mergify mergify bot closed this as completed in #122 Apr 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant