3 ms·

Probably the most succinct comparison of Nix and Docker I've seen. So this works by having Stack (a Haskell build tool?) emit a nix file to build a Haskell pro

Probably the most succinct comparison of Nix and Docker I've seen. So this works by having Stack (a Haskell build tool?) emit a nix file to build a Haskell project? Very cool. The more natural approach for this seems to be to use your language's package manager spec as a base to build Nix packages. Since package manager spec files already contain build instructions, this frees you up from any dependency on a specific build system. It would then be straightforward to generate Nix packages from a repository and serve them through a Nix channel. All that being said, I should implement this for OCaml and OPAM. Nix is amazing, but it is "all-in." Native Nix builds the right way involve all your dependencies being Nix packages. (Nix builds using a language's package manager are impure and would likely require hand-holding with external deps.) This article seems like a nice step towards solving that, but I think the real solution would be tooling around the package manager itself.

Ericson2314 11y ago
> The more natural approach for this seems to be to use your language's package manager spec as a base to build Nix packages. Since package manager spec files already contain build instructions, this frees you up from any dependency on a specific build system. It would then be straightforward to generate Nix packages from a repository and serve them through a Nix channel. Yeah `Stack.yaml` is weird because it is both manually edited and generated. I'd rather see a split where the `Cabal-file + overrides/extra-info => build-plan` (not any central package db is not consulted). Then either Nix, or the built-in default can interpret that build plan (and just the build-plan) to actually build the thing. We can add a feedback loop `Cabal-file + overrides/extra-info + Maybe(solved-versions) => build-plan solved-versions` analogous to Cargo's and Bundler's lockfiles too. Basically the goal is to separate the less deterministic aspects of querying versions and solving constraints, vs the entirely determinstic simple-stupid steps of actually building things. Ideally then, nixpkgs would need no knowledge of upstream packages, and just the ability to interpret build-plans per language package manager. Caching would follow from just making sure the build-plan didn't very in stupid ways (of course the nix interpretation of the build-plan should be deterministic). For system packages relying on a langauge package manager (xmonad...) use a "dynamic import" (import result of derivation) to avoid the need of caching these steps in the nixpkgs source.

Ericson2314 11y ago

> The more natural approach for this seems to be to use your language's package manager spec as a base to build Nix packages. Since package manager spec files already contain build instructions, this frees you up from any dependency on a specific build system. It would then be straightforward to generate Nix packages from a repository and serve them through a Nix channel. Yeah `Stack.yaml` is weird because it is both manually edited and generated. I'd rather see a split where the `Cabal-file + overrides/extra-info => build-plan` (not any central package db is not consulted). Then either Nix, or the built-in default can interpret that build plan (and just the build-plan) to actually build the thing. We can add a feedback loop `Cabal-file + overrides/extra-info + Maybe(solved-versions) => build-plan solved-versions` analogous to Cargo's and Bundler's lockfiles too. Basically the goal is to separate the less deterministic aspects of querying versions and solving constraints, vs the entirely determinstic simple-stupid steps of actually building things. Ideally then, nixpkgs would need no knowledge of upstream packages, and just the ability to interpret build-plans per language package manager. Caching would follow from just making sure the build-plan didn't very in stupid ways (of course the nix interpretation of the build-plan should be deterministic). For system packages relying on a langauge package manager (xmonad...) use a "dynamic import" (import result of derivation) to avoid the need of caching these steps in the nixpkgs source.