3 ms·
My preferred approach is to use one of those `foo2nix` tools, but as part of the build process (using the "import from derivation" feature of Nix). There's no n
by chriswarbo 2y ago
My preferred approach is to use one of those `foo2nix` tools, but as part of the build process (using the "import from derivation" feature of Nix). There's no need to keep such build products in git.
I've done this professionally for Maven projects (mostly Scala) via mvn2nix, and personally I've been doing it for many years with Haskell via cabal2nix (Nixpkgs now has `haskellPackages.callCabal2nix`; before that I was hacking together similar things like https://github.com/Warbo/nix-helpers/blob/45a66d714877233680e82c55a4930ed0565aef9a/helpers/mkStableHackageDb.nix https://github.com/Warbo/nix-helpers/blob/45a66d714877233680... )
- xyzsparetimexyz 2y ago>There's no need to keep such build products in git. There is when the bridged build system doesn't use hashes, like requirements.txt.
- chriswarbo 2y agoYes, that's covered in the article, e.g. > Input data, especially descriptions of available dependencies, should be specified such that we can reproduce it for any previous run. This is the problem many legacy systems struggle with: e.g. deferring important details to some HTTP response, with no way to validate its consistency (it’s usually not consistent, due to new versions being included in queries!). This is the main problem with legacy tools, which makes their users resort to lock files. The article is pointing out that these are mistakes, in the hope that developers of new packaging tools will stop copying them. In the mean time, those of us stuck using those tools will need to keep working around their problems using hacks like lock files.