3 ms·

You can mitigate this to some extent by approaching it as described here: https://www.haskellforall.com/2022/08/incrementally-package-haskell-program.html http

You can mitigate this to some extent by approaching it as described here: https://www.haskellforall.com/2022/08/incrementally-package-haskell-program.html https://www.haskellforall.com/2022/08/incrementally-package-... I think Graham Christensen had a blog post along these lines... I'll see if I can find it. Edit: I couldn't find it... but I thought someone made a blog post about gradual adoption of Nix into a codebase.

pxc 3y ago
Idk about a blog post, but he did a talk along those lines at the most recent NixCon: https://youtube.com/watch?v=asc1D5yPZhQ& https://youtube.com/watch?v=asc1D5yPZhQ& I'm taking that approach with the package I've been working on, which has a somewhat pathological (by Nix standards) Gradle build which does things like - manually download a copy of Elastic search outside of the normal Java dependencies scheme - run NPM to fetch remote libraries to build web assets at build time - *also* run Yarn, for some reason - use Git at build time The ways it does all of these things are actually fairly thoughtful (for example, it does checksum the artifacts it manually grabs at build time to verify their contents), but they don't play nice with running builds in offline mode or under a user that has no $HOME. But it's one of those freeform 'my build tool configuration is a weird DSL in an imperative, general purpose, Turing-complete language' situations, and I'm not very familiar with either the language (Groovy) or the DSL. So it's a lot of quirks to cope with. I've made quite a bit of progress in building it from source by making a few small patches and eventually disabling the sandbox for now, but it's still dying on a weird test failure for reasons I don't yet understand. At this point I'm just back to munging the binaries provided by upstream because I was mostly building from source to learn about the project and how it's distributed/deployed anyway. I messed a bit with gradle2nix for a better-behaved, old school FOD-based build with Gradle in offline mode, but that was pretty brittle as gradle2nix is unmaintained, and due to some design limitations it couldn't actually capture all dependencies. I'm kinda interested in working out something better but on the other hand, this is a third-party package and I don't myself use Gradle or Groovy for any kind of development, so mastering Gradle's quirks and wrangling it into the Nix sandbox for this package is more of a yak shave than a practical skills investment for me.

pxc 3y ago

Idk about a blog post, but he did a talk along those lines at the most recent NixCon: https://youtube.com/watch?v=asc1D5yPZhQ& https://youtube.com/watch?v=asc1D5yPZhQ& I'm taking that approach with the package I've been working on, which has a somewhat pathological (by Nix standards) Gradle build which does things like - manually download a copy of Elastic search outside of the normal Java dependencies scheme - run NPM to fetch remote libraries to build web assets at build time - *also* run Yarn, for some reason - use Git at build time The ways it does all of these things are actually fairly thoughtful (for example, it does checksum the artifacts it manually grabs at build time to verify their contents), but they don't play nice with running builds in offline mode or under a user that has no $HOME. But it's one of those freeform 'my build tool configuration is a weird DSL in an imperative, general purpose, Turing-complete language' situations, and I'm not very familiar with either the language (Groovy) or the DSL. So it's a lot of quirks to cope with. I've made quite a bit of progress in building it from source by making a few small patches and eventually disabling the sandbox for now, but it's still dying on a weird test failure for reasons I don't yet understand. At this point I'm just back to munging the binaries provided by upstream because I was mostly building from source to learn about the project and how it's distributed/deployed anyway. I messed a bit with gradle2nix for a better-behaved, old school FOD-based build with Gradle in offline mode, but that was pretty brittle as gradle2nix is unmaintained, and due to some design limitations it couldn't actually capture all dependencies. I'm kinda interested in working out something better but on the other hand, this is a third-party package and I don't myself use Gradle or Groovy for any kind of development, so mastering Gradle's quirks and wrangling it into the Nix sandbox for this package is more of a yak shave than a practical skills investment for me.