Why not purs-nix instead of spago and spago2nix

[klarkc]

CTL is using its own prelude, and nix for a lot of things, it should be also using nix to reduce boilerplate. I tested it here, and this is the result: https://github.com/LovelaceAcademy/cardano-transaction-lib/tree/develop/templates/la-scaffold

To achieve it, I forked purs-nix and its registry and added my own namespace with pinned dependencies following the spago package-set. For the CTL dependencies, I forked it and added the missing flake files.

It's still missing test things (like Plutip), but I liked the result, so I am sharing it here.

[klarkc]

purs-nix also supports bundling through esbuild natively, so it also aligns with #79. On #400 resolution, it will also remove webpack dependency.

[klntsky]

Thank you for sharing!
Changing nix machinery that much is out of scope at this stage of the project anyways, but what do you think would be the benefits of using purs-nix?

[klarkc]

@klntsky From haskell and javascript devs perspective, I believe it will be beneficial to reduce the boilerplate to get started, it's easier to deal with a single domain-specific language (nix) instead of two (nix and dhall). It scares a lot to have such boilerplate (npm packages, nix flakes and spago dhalls). Another way around would be to remove nix and use spago only, but I don't think it's feasable at the current stage.

[klarkc]

Oh there are other three benefits:

• using nix flakes alone as packaging solution allow us to embed CTL FFI deps with the derivation, so there is no need to the CTL's user declare CTL FFI runtime deps like here, it would be embeded in the nix flake through purs-nix, you can see it here and here;
• with everything in place, the upgrade process, would be as simple as running nix flake update, no more unexpected bugs by missing spago/npm upgrades (given namespace packages being maintained);
• with the eventual webpack removal, npm turns to be totally optional, so the CTL will only depend on nix to be used as a library.

[klntsky]

We don't have a goal of making nix the only building method.
We also need incremental builds and hot reloading for dev environment.

with the eventual webpack removal

It may or may not happen, see this thread. There are shortcomings in every other tool. Anyway, moving away from webpack is not scheduled for the current milestone at least.

no more unexpected bugs by missing spago/npm upgrades

This is going to be addressed by #1076

[klarkc]

I understand, anyway I'll try to keep this fork in sync with stable CTL releases, for anyone looking for a nix-only solution.

[klarkc]

We also need incremental builds and hot reloading for dev environment.

Just to clarify for anyone interested in the nix-only solution: There is no issue with incremental builds or hot-reloading with the proposed solution, it's working in our fork, we're using CTLs webpack config now just because we depend on #400 to remove it. You'll not need npm boilerplate to have incremental builds and hot-reloading, with the proposed solution.

[klarkc]

Update: the fork has been archived, moved to LovelaceAcademy/ctl-nix.

This issue is a wont fix? Please let me know if I should close it. Thanks!

[klntsky]

@klarkc sorry for late reply. I think we should give it a try, but we can't allocate resources for that at the moment.

[klarkc]

No problem, it's already working, as you can see in this demo https://github.com/LovelaceAcademy/nix-templates/tree/main/pix-ctl-full

I totally understand, maybe going fully on Nix is out of the scope of the project right now. Also I should mention that there is a new alternative being developed Purifix that also might fit better in your scenario.