Closed jmatsushita closed 2 years ago
https://github.com/turion/rhine/runs/6568785125?check_suite_focus=true fails with error: overlay does not take an argument named 'final'
. The nix version used is 2.8.1.
Here's a very simple flake (following up on #162) which uses the experimental
haskell-flake-utils
approach which is the only tool I know that simulates someone a simple multi package setup with cabal (it doesn't do anything with thecabal.project
file, instead it takes an argument where we can specify which packages needs to be built).It allows to do
nix build .#rhine-gloss result/bin/rhine-gloss-gears
nix develop cabal build rhine #or cabal run rhine-gloss-gears
Awesome!
I've tested this on
aarch64
andx86_64-linux
and the added CI job should test building on linux. Though I expect thatnix flake check
will fail with:error: overlay does not take an argument named 'final'
Indeed it does.
(I've reported this bug to
haskell-flake-utils
ivanovs-4/haskell-flake-utils#2
And it seems it's fixed upstream yesterday :tada: can you bump haskell-flake-utils
and we try again?
It builds using GHC 9.0.2 which is the default compiler in nixpkgs stable at the moment. It's not obvious how to build for multiple GHC versions with this utility
That's good enough for a start :)
* [ ] Settle on `haskell-flake-utils` or a more manual approach.
Let's see whether the upstream fix works. If yes, keep it, if no, a more manual approach.
* [ ] Update default.nix and shell.nix with `flake-compat` for legacy compatibility (as [described here](https://nixos.wiki/wiki/Flakes#Using_flakes_project_from_a_legacy_Nix))
Yes makes sense :)
* [ ] Remove other `*/shell.nix` and `*/default.nix` files.
I guess not, it contradicts the previous idea.
* [ ] Decide if maintaining stack build makes sense (I couldn't build with the current stack configuration)
I don't care about stack at all, but maybe @miguel-negrao is motivated to fix it :grinning:
* [ ] Update README
Yes.
* [ ] Add local development tooling (HLS, ghcid, hoogle...)
I don't know how HLS from the flake interacts with the editor. I'd leave these points out for now.
* [ ] Add a gitpod configuration to be able to have a cloud based development setup
No idea what that is :sweat_smile:
* [ ] Find a solution for multi compiler builds
Yes, that can be a separate issue.
Happy to keep adding to this PR and discuss as we go or merging smaller blocks of work, as you prefer.
I prefer smaller blocks. Too big PRs tend to get stuck.
Can you comment in the readme how to use the flake?
Sure thing will do.
Saw the upstream fix, and will bump it!
Let's see whether the upstream fix works. If yes, keep it, if no, a more manual approach.
There are other concerns, but I'd like to merge this and submit another PR for discussing what other approaches would entail.
- [ ] Remove other
*/shell.nix
and*/default.nix
files.I guess not, it contradicts the previous idea.
I meant the rhine/shell.nix
rhine-examples/shell.nix
and so on. Unless there's something I'm missing in your workflow, it should be possible to enter the nix develop
shell and build all packages together or individually.
I don't know how HLS from the flake interacts with the editor. I'd leave these points out for now.
That's one of the reasons I use flakes and nix :D It works very well, but I agree let's do this in a subsequent PR :)
- [ ] Find a solution for multi compiler builds
Yes, that can be a separate issue.
Should work with this other upstream fix
I prefer smaller blocks. Too big PRs tend to get stuck.
Sounds good!
Thanks a ton for the review, and super excited about your (conceptual) fixes on the terminal
PR. Will fix this PR and look at the other one sometime this week 👍
Let's see whether the upstream fix works. If yes, keep it, if no, a more manual approach.
There are other concerns, but I'd like to merge this and submit another PR for discussing what other approaches would entail.
Great.
- [ ] Remove other
*/shell.nix
and*/default.nix
files.I guess not, it contradicts the previous idea.
I meant the
rhine/shell.nix
rhine-examples/shell.nix
and so on. Unless there's something I'm missing in your workflow, it should be possible to enter thenix develop
shell and build all packages together or individually.
Oh, I see! Yes, let's remove those.
I don't know how HLS from the flake interacts with the editor. I'd leave these points out for now.
That's one of the reasons I use flakes and nix :D It works very well, but I agree let's do this in a subsequent PR :)
Ok, looking forward to that :)
Hi @turion
I think I've addressed all your comments. There are a couple of loose ends.
Regarding systems
, Github actions can build x86_64-linux
and x86_64-darwin
(and maybe i686-linux
but not sure how) and I've created a matrix for that in CI, but I'd like aarch64-darwin
to be included in the flake since this is needed on my laptop (but not available in Github runners as of yet - except if self-hosted).
Also, unfortunately, despite the fix to overlay does not take an argument named 'final'
nix flake check
to run tests isn't quite ready (part of the flake things that haven't been quite worked out yet) and will fail with something like:
error: a 'aarch64-linux' with features {} is required to build '/nix/store/ci2j3y5cc4mhm5hpl3zkq05ix6429094-cabal2nix-rhine.drv', but I am a 'aarch64-darwin' with features {benchmark, big-parallel, nixos-test}
This is a known issue and the alternatives are:
cabal2nix
manually and generating package.nix
files which will need to be kept manually (or maybe with a pre-commit hook) in sync with the .cabal
files. Or the more experimental (and super cool) https://github.com/cdepillabout/cabal2nixWithoutIFD nix flake check
until the issue is fixed and instead use a different check
attribute which can be ran with nix build .#check.x86_64-linux
.Happy to open another issue to figure that one out :) For now I've added a nix develop -c cabal test all
command to run tests... And then realised there were no tests yet 🤣 (it's ok though, no tests is a passing test suite).
Also I've tested this PR together with https://github.com/turion/rhine/pull/166 and running stack build
(with nix enabled system wide on my machine) seems to work well. Awesome @miguel-negrao !
Cheers,
Jun
Awesome :) two systems built is already great!
Let's leave out nix flake check
for the moment. The tests (when they're added) can be run on the cabal jobs for the time being.
That's great. Will open a new PR for adding haskell language server and look into the multi compiler setup. 👍
Hi @turion
Here's a very simple flake (following up on #162) which uses the experimental
haskell-flake-utils
approach which is the only tool I know that simulates someone a simple multi package setup with cabal (it doesn't do anything with thecabal.project
file, instead it takes an argument where we can specify which packages needs to be built).It allows to do
I've tested this on
aarch64
andx86_64-linux
and the added CI job should test building on linux. Though I expect thatnix flake check
will fail with:(I've reported this bug to
haskell-flake-utils
https://github.com/ivanovs-4/haskell-flake-utils/issues/2It builds using GHC 9.0.2 which is the default compiler in nixpkgs stable at the moment. It's not obvious how to build for multiple GHC versions with this utility
Some things to consider moving forward:
haskell-flake-utils
or a more manual approach.flake-compat
for legacy compatibility (as described here)*/shell.nix
and*/default.nix
files.Add local development tooling (HLS, ghcid, hoogle...)for laterAdd a gitpod configuration to be able to have a cloud based development setupfor laterFind a solution for multi compiler buildsfor laterHappy to keep adding to this PR and discuss as we go or merging smaller blocks of work, as you prefer.