Define a distribution constraint setting about platforms

[gregestren]

@aiuto for reference (who else should be reading these?)

What's the practical difference of the different distributions? Can it be boiled down to the paths where the tools end up? I wonder if the tool_paths proposal described in Non-Hermetic Tool Paths in Platforms speaks to this?

[mboes]

That proposal looks relevant. But I'm struggling to visualize how it will work in this case. To summarize:

1. Bazel isn't 100% hermetic. Rule sets typically provide macros to download prebuilt toolchains in external repositories. These prebuilt toolchains make arbitrary assumptions about the host environment (like glibc version, location of dynamic linker, etc) that are unaccounted for in the build description. That's a problem (and in my experience daily, not a theoretical one).
2. If we're going to have non-hermetic workspace rules to provision toolchains (like rules_go or rules_nodejs do), we're going to have to offer users some control. If my system has a different glibc than the Go SDK's assume, or a dynamic linker at a different location, I will need a) alternatives to the SDK's and b) a means to select which alternative I want.
3. The alternatives could be "fat" packages (much like "uber jars") that are closures containing everything. Flatpak, AppImage, Nixpkgs are all examples of this. At least these types of packages work on any system without making assumptions like SDK's do. And like downloading SDK's, unpacking these packages does not require any superuser priviledges.
4. Even if we use "fat" packages, no one such fat package type is a one size fits all: there is no de facto standard here and some users prefer Nixpkgs, some other prefer something else, and others want to stick to non-hermetic SDK's rather than bother with any such fat packages that eat up a substantial amount of space on disk.
5. We can provide these alternatives and the means for the user to select among them today. We just need to agree on a constraint_setting name to select between say pulling toolchains from a Nixpkgs, or from a Flatpak package, or ...

So what should that constraint_setting name be, and does it have a place in this repository?

[gregestren]

I'd like to think the right path forward would involve enhancing rule sets' toolchain definitions to auto-configure as necessary. The theoretical tool_paths could fill out the pieces they leave as open variables.

But I understand constraint_settings can have a role to play here too. There are a few discussions / docs floating around trying to figure out how to manage the variety of compilers, compiler versions, runtime versions, etc. installed on diferent machines and how to provide the right flexibility to choose the right ones. I guess a lot of them are assuming the continuation of non-hermetic distributions.

Another example is Versioned Runtime APIs under
Platforms & Toolchains, which also speaks to adding new constraint_settings for platforms, albeit at a more granular level.

[aiuto]

@aragos @katre @agoulti @iirina

[aiuto]

So what should that constraint_setting name be, and does it have a place in this repository?

Those are hard questions. The easy question is "does this idea make sense", to which the answer is yes. I think. My understanding of your proposal is basically

• auto-configuring, hon-hermetic toolchains will eventually download packages from some package manager repository
• the tool owner will have to provide capability to do the download and configure (probably with common tooling for many toolchains)
• the user rather the owner will want the capability to say what kind of package manager they want

The cross product of the 3 things gets a configured tool chain with binaries downloaded from a place of the user's choice.

Before we can figure out the name, we need to know if we want to talk about specific package managers (SaltStack vs. Chocolatey) or do we talk about my OS distribution (Nix vs RedHat). Or both?

Then the question is if this repository is the right place. I think yes if there is going to be common infrastructure for downloading things from different kinds of repositories and the toolchain implementations will share it.

Can you come with a proof of concept that demonstrates the kind of thing you want to do?
Once we figure out which kind of thing makes sense, the naming should fall out of it.

[mboes]

Before we can figure out the name, we need to know if we want to talk about specific package managers (SaltStack vs. Chocolatey) or do we talk about my OS distribution (Nix vs RedHat). Or both?

My hunch is that it should be only the former. There are two use cases under discussion:

1. Non-hermetic builds with non-hermetic toolchains.
2. Hermetic builds, which use toolchains built outside of Bazel that are nonetheless hermetic because they are closures (e.g. a Nix derivation, a Docker container, a snap...).

In use case 1, distro-specific differences are either dealt with via auto-configuration or with constraint settings but these should be more granular than just centos or nixos (which the user is free to define as platforms). So we're left with just use case 2. In this case, we want to choose an appropriate source of toolchain, and this isn't a matter of autoconfiguration: it's as legitimate for a CentOS user, and even a macOS user, to source toolchains using Nix as it is for a NixOS user. It really is up to the user to specify the source of the toolchains.

So I guess distribution isn't a fantastic name. Perhaps package_manager? In very large projects, it's conceivable that one part of the build will use one package manager while using another package manager for other parts because say a Nix package exists but not a Flatpak one for some particular toolchain. This however, should be rare. And hopefully multiplatform builds (see bazelbuild/bazel#6519) will happen someday, at which point it won't be a problem.

[mboes]

How do we make progress on this front?

[mboes]

Another ping.

[mboes]

@gregestren thinking about this more, perhaps a generic package_manager constraint setting is misguided: package managers are not necessarily mutually exclusive. Perhaps it makes more sense to have multiple "feature test" style constraint settings, like nix with a single support_nix constraint value, flatpak with a single support_flatpak, etc.

Constraint settings still have a role, beyond the question of finding the right path for compilers. Because sometimes a specific tool (like the package manager) has to be called to populate a global content addressable store and have paths to point to. But if you agree with the first paragraph above, we can close this issue.

[gregestren]

@mboes I'm trying to get back on track with these themes. Please give me some more time to think through your points more thoroughly before I can offer a reasonable response. This is up-prioritized in my queue.