Hello Timothy and Robert, (a little OT re cabal import, but...) sorry if I repeat something already said on this list... and sorry for a *personal* rant :-) Timothy Sample writes: [...] > IIRC, Nix automatically imports all Haskell packages from Hackage (I’m a > little fuzzy on the details, though). https://github.com/NixOS/nixpkgs/blob/release-19.03/pkgs/development/haskell-modules/hackage-packages.nix --8<---------------cut here---------------start------------->8--- /* hackage-packages.nix is an auto-generated file -- DO NOT EDIT! */ --8<---------------cut here---------------end--------------->8--- Please do not this in Guix. I don't have details about auto imported Haskell packages reproducibility in Nix, I just remember other *historical* approaces with Javascript packages in a fine 2015 analisys by Christopher Lemmer Webber https://web.archive.org/web/20180528141816/http:/dustycloud.org/blog/javascript-packaging-dystopia/ «Unfortunately, Nix just downloads the prebuilt binary and installs that» Today Nix ships this jquery related packages: https://nixos.org/nixos/packages.html#jquery and AFAIU jquery (python37Packages.xstatic-jquery, haskellPackages.js-jquery) are still static prebuilt binaries Are they counted as reproducible by this kind of checks: https://r13y.com/ ? [...] > One of the main issues with automatic package maintenance in Guix is > that we have some unconventional, non-technical and semi-technical > requirements on our packages. We need to follow the FSDG (Free > Software Distribution Guidelines); we try and make sure that > everything has a useful synopsis and description; and we try to make > sure everything is bootstrappable and reproducible. I say > “unconventional” above because there are often upstream issues with > these things that need to be fixed manually. Re. reproducibility, unfortunately it's **not** a shared goal between _packaging systems_ developers, so for example we have a good pile of npm packaged code that is _still_ a *nightmare* from the reproducibility POV Hey developers: please come and work with Guix on a reproducible way to build and distribute software; Guix have all it's needed, please stop reinventing the *square* wheel. Citing Christopher article above: «And let's face it, "fuck it, I'm out" seems to be the mantra of web application packaging these days. Our deployment and build setups have gotten so complicated that I doubt anyone really has a decent understanding of what is going on, really.» AFAIU this is _still_ the sad situation today with web applications development, probably 99% of web developers/deployers in the world are "solving" this with Docker app bundles containing piles of misterious layers of mixed reproducible and static binaries downloaded _somewhere_, cryptominers included There are succesful projects out there that _proudly_ declare the *only* officially supported distribution method is their Docker bundle... World: **we have a problem** https://web.archive.org/web/20180528121826/https://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html «Feels like downloading Windows shareware in the 90s to me.» I don't know the reproducibility situation with Stackage or Hackage defined packages (and web applications), I just hope it's better than this. Re. boostrapping, unfortunately we still have an unbootstrappable Haskell toolchain https://web.archive.org/web/20190615075205/http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html ...but that's the same with some jvm languages http://bootstrappable.org/projects/jvm-languages.html Anyway at least "the plan" to work it out is in good shape... the world just needs to invest much more resurces on this serious infrastrutcure problems, but it's too... distracted :-D Last but not least: a huge pile of deep gratitude to all the people around the world working to solve this sad sad situation! Happy Guix! Gio'. [...] -- Giovanni Biscuolo Xelera IT Infrastructures