* Packages in Nix are defined as functions (so called derivations)
* Package dependencies are function parameters
* You can override dependencies by simply passing different arguments
* Nix derivations are fully overridable:
* you override the source - tell Nix to get the source from a local directory, ssh+git repo, hosted VCS like GitHub/GitLab/..., package registry like NPM, Cargo, etc.
* You can apply patches on top of the source
* You override compiler flags, build system options, or the entire build recipe
* Force enable/disable the tests of all or a specific package in your dependency graph (so called closure in Nix)
* Nix will automatically figure out if it needs to build the package from source or download a binary artifact. This is the so called substitution or binary cache - you can disable a particular cache or add additional ones. Sort of like pulling different layers of a docker image from different docker registries. The difference being that Docker only keeps the image in the registry, while Nix always has the build recipe and you can reproduce it at will.
Github actions marketplace, should allow different channels to add the last steps for publication to different registries.
Tools wide enough might be a challenge, but if you already build your package through code or configuratión you just need a compatible action.
Bazel might be general enough to compile any language, in an incremental and effective way. This could happen in the requester's computer, a bigger infra, or just using build resources in github.
So recapping:
Ideally as a dev
We are saying that:
One adds a docker image
And an automáted build process
Goes into the marketplace, gets a general build plugin, selects distribución channels or accepts the default and voila
He's left with development only flows
Meanwhile first requester's in any distribución channel contribute to the registro and end up verifying QAing the final builds (should not be a problem as everything is dockerized and using reliable build systems)
You have basically described Nix :)
* Packages in Nix are defined as functions (so called derivations)
* Package dependencies are function parameters
* You can override dependencies by simply passing different arguments
* Nix derivations are fully overridable:
* you override the source - tell Nix to get the source from a local directory, ssh+git repo, hosted VCS like GitHub/GitLab/..., package registry like NPM, Cargo, etc.
* You can apply patches on top of the source
* You override compiler flags, build system options, or the entire build recipe
* Force enable/disable the tests of all or a specific package in your dependency graph (so called closure in Nix)
* Nix will automatically figure out if it needs to build the package from source or download a binary artifact. This is the so called substitution or binary cache - you can disable a particular cache or add additional ones. Sort of like pulling different layers of a docker image from different docker registries. The difference being that Docker only keeps the image in the registry, while Nix always has the build recipe and you can reproduce it at will.
* Since Nix knows your complete dependency graph, you can bundle your app (or entire OS) in a variety of formats, including Docker: https://github.com/nix-community/nixos-generators#supported-formats
* Nix is a killer tool for building polyglot apps - e.g. combining (building and linking in Wasm modules) Rust, C++ and Nim code
Github actions marketplace, should allow different channels to add the last steps for publication to different registries.
Tools wide enough might be a challenge, but if you already build your package through code or configuratión you just need a compatible action.
Bazel might be general enough to compile any language, in an incremental and effective way. This could happen in the requester's computer, a bigger infra, or just using build resources in github.
So recapping:
Ideally as a dev
We are saying that:
One adds a docker image
And an automáted build process
Goes into the marketplace, gets a general build plugin, selects distribución channels or accepts the default and voila
He's left with development only flows
Meanwhile first requester's in any distribución channel contribute to the registro and end up verifying QAing the final builds (should not be a problem as everything is dockerized and using reliable build systems)