Support for NixOS

[AleksanderGondek]

Description of the feature request:

At the moment, rules_gitops will not work when used on NixOS host.
This feature request, asks for adding built-in support for aforementioned operating system.

Details:
Due to its nature, NixOS rigidly separates package dependencies, down to ELF interpreters - everything
is symlinked and kept isolated. The system itself, does not and should not have files like /lib/ld-linux.so.2, nor has it libraries present in default, global namespaces.

Consequently, binaries which are produced in 'default manner' often fail to work on NixOS (quite frequent, due to no RPATH or default ELF interpreter).
More details can be read here.

This incompatibility could be a source of major pain, while using most of Bazel rules, however it is possible to
configure golang sdk, so that it will built binaries correctly - see the details here.

Unfortunately, pre-configuring golang sdk is not enough to make the rules_gitops compatible, as it downloads pre-built
kustomize binary. This differentiates it from bazelbuild/rules_k8s or bazelbuild/rules_docker where such pre-configuration is enough.

This feature request, postulates to detect if rules are executed on NixOS, and - if and only if - they are indeed executed on NixOS, use built into the OS mechanism for obtaining kustomize binary.

Feature requests: what underlying problem are you trying to solve with this feature?

Currently I have to apply custom patches to rules_gitops to make it work on NixOS machines - I would rather treat it in the same manner other, similar Bazel tools (rules_k8s, rules_docker).

It may seem trivial to add few patches in one project, but keeping track of it in many WORKSPACES is tedious.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Use NixOS (20.09) host
2. Clone the example project: link
3. Remove patches fixing the issue WORKSPACE lines 33 and 34
4. Run $ bazel build //kubeview:kustomize-dev

What operating system are you running Bazel on?

NixOS 20.09

What's the output of bazel info release?

release 3.3.1- (@non-git)

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

It was installed by nix package manager link.

Snippet of the WORKSPACE file that includes rules_gitops rules.

...

load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

git_repository(
  name="com_adobe_rules_gitops",
  commit="354e7d3341f05e076f286663731f18caf1e62340",
  remote="https://github.com/adobe/rules_gitops.git",
  shallow_since="1611050644 +0000",
)
load("@com_adobe_rules_gitops//gitops:deps.bzl", "rules_gitops_dependencies")
rules_gitops_dependencies()

...
load("@com_adobe_rules_gitops//gitops:repositories.bzl", "rules_gitops_repositories")
rules_gitops_repositories()

Have you found anything relevant by searching the web?

• Why most binaries need patching on NixOS - link
• Running golang-based Bazel rules on NixOS - link

Any other information, logs, or outputs that you want to share?

In connection with closing of issue 52, this would make adobe/rules_gitops support NixOS nearly out-of-the-box.

[kzadorozhny]

We don't have an issue with adding NixOS support in general. But there are couple aspects we need to consider before we can a accept it.

We need to have CI pipeline that validates NixOS support. We will not accept new OS support without the e2e test.

Same as with #22, #46, the #55 builds on functionality that need to be replaced with a toolchain. The toolchain support is planned, but there is no timeline when it will be done, tough.

I think the best short term strategy is to finalize NixOS support in your own fork. We would happily upstream this work once the toolchain support lands.