Why not purs-nix instead of spago and spago2nix

Plutonomicon / cardano-transaction-lib

A Purescript library for building smart contract transactions on Cardano

https://plutonomicon.github.io/cardano-transaction-lib/

MIT License

93 stars 51 forks source link

Why not purs-nix instead of spago and spago2nix #1085

Open klarkc opened 2 years ago

klarkc commented 2 years ago

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 commented 2 years ago

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

klntsky commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/Plutonomicon/cardano-transaction-lib/issues/1076

klarkc commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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.