Move Wasp from Stack to Cabal

[Martinsos]

Cabal is now in a very good shape, its development is going well and it is being supported by HF.

On the other hand we often encounter bugs with Stack, be it server outage, or some smaller bug, or bugs related to tooling: e.g. lsp doesn't work correctly across different parts of package (exec, lib, tests). This latest bug is the biggest problem, as it makes TDD really hard, and it has been open for long time now and there is no indication of it getting fixed soon.

Therefore, the idea is to switch to Cabal!

[Martinsos]

How Hasura migrated to Cabal from Stack: hasura/graphql-engine#3280 .

[philderbeast]

How are you getting on with this @Martinsos? I've checked out the stack-to-cabal branch. Would it be possible to commit the cabal file generated from package.yaml as the first commit so we can see what needed to change, as a starting point?

Have you considered trying hpack-dhall? The dhall-lang description is "Maintainable configuration files" and I wholeheartedly agree.

It could help with pulling in files from globs (haskell/cabal#5883 (comment)).

If going the hpack-dhall route then I'd start by writing a package.dhall and use a diff tool to ensure that I can generate the existing package.yaml (using dhall-hpack-yaml) and waspc.cabal (using dhall-hpack-cabal).

[Martinsos]

@philderbeast thanks for checking in :)!
I actually just did some serious work on this today, check it out now -> it is very close to being done!

I did the start as you said -> I used as a starting point what stack generated.

I like the idea behind "Maintainable configuration files", so I should certainly give it a look, tnx for sharing! I might postpone it a bit till we get this working first though, just so I don't change too many things at once, but I would certainly like to avoid listing all the modules in cabal file, and all the data files, and similar.

The main thing missing with stopping me from merging the current solution (#471) is figuring out how freeze works, but I think I am getting close to that with haskell/cabal#8047 (thanks for help there!)
Once we figure that out, I need to update the README with instructions for using cabal, and I can think we can merge that PR and pronounce migration to cabal done. And then we can also look at options like dhall or hpack, potentially.

Btw what do you think about the way I implemented running of stan, hlint and ormolu? Check run script to see how they are installed and run. I use dev-tool.project as cabal project file for these. I based this solution based on our previous discussion.

[philderbeast]

Btw what do you think about the way I implemented running of stan, hlint and ormolu?

That's some bash script wizardry! Each of those tools is taking about 10 mins to build at first run. They're not being run in CI (ormolu used to be).

I see package.yaml still exists.

[Martinsos]

Btw what do you think about the way I implemented running of stan, hlint and ormolu?

That's some bash script wizardry! Each of those tools is taking about 10 mins to build at first run. They're not being run in CI (ormolu used to be).

I see package.yaml still exists.

Oh wow you are right, I left the package.yaml behind by accident, removed it now!

Yeah, they take 10 minutes first time to build. I didn't know a better way to do it unfortunately, while still having them be local to the project, and I like this concept of being able to install them local to the project with just one command.

hlint and stan are not used in CI yet since we didn't resolve all of the errors, but ormolu actually is! It is run in CI via ./run ormolu:check.