[WIP] Add flake #2517
[WIP] Add flake #2517
Conversation
|
back trace of the |
|
I honestly don’t understand what we get out of adding the flake support to this repository @hamishmack , why do we need this? What is the cost-benefit ratio here? Is there a problem that needs fixing to which flake is the answer? One thing to note before going into any ofher details: We recently set up a nice GitHub action providing automatic PRs for when niv sources are updated. I like that. That is clearly gone then. |
I am not sure yet. So far trying out flakes has not been smooth sailing. There is the seg fault above and
In theory better caching of evaluation results. I'm updating the haskell.nix getting started guide and would like to include better instructions for both Other advantages:
I am also curious to know if the performance benefits of flakes require that we use |
|
Here is an example of how much faster flakes can be when the eval is cached: Without using flakes: Using flakes: |
Actually this segfault alone is a total blocker to me. I've never had the current Nix setup segfault on me in any way and i've done a lot of refactoring the past weeks. I am not eager to introduce something that segfaults on very basic interactions (such as
If they don't segfault... As for caching the majority of people seem to be using
|
I do understand and acknowledge this. Yet I still don't think this is a valid answer to: "What problem(s) would nix flakes solve that people working on this project have?" Some plutus developers don't even use nix much at all, everyone else seems to be using lorri (there are also options like https://github.com/nix-community/nix-direnv or https://github.com/nmattia/sorri). I don't think that anyone is currently held back by Nix evaluation times. So Nix evaluation times don't appear to be a problem that needs fixing in the daily developer workflow. Evaluation takes quite some time on hydra but i think that is a different matter. We might want to try and actually improve overall evaluation time. That would require profiling/evaluating bottlenecks which i haven't been able to do on my 64GB RAM desktop - @michaelpj recently created a haskell.nix on |
|
I don't mind trying it out in a PR, but I'm with @gilligan in that flakes feel pretty alpha-quality to me now, and I'm not that interested in being an alpha-tester at the moment (considering Nix is arguably already beta-quality at best 😅 ). However, I guess there might be a bit of missing context here. Is the point of this also so we can deploy |
|
Hm, does the use of bitte thus enforce flakes on any package/project that is to be deployed with it? That would seem somewhat odd. If the actual motivation behind all of this is indeed being able to deploy something, and deploying absolutely requires a flake, i would hope that some much less intrusive shim could be provided for this purpose. Also if it was only for deploying web-ghc (and nothing else) all the required effort maybe would not be justified? Maybe i am missing the big picture or some insight - sorry in that case. |
|
Seg fault seems likely to be this NixOS/nix#4264. It does not seem to seg fault when |
|
|
|
@hamishmack i guess we won't proceed with this for now - mind if we close this? You can keep your WIP branch around of course. |
@manveru, I found a couple of places where
nix/sources.nixwas still used instead ofsources. Putting a dummyrevvalue in gets rid of one of them (I guess theiohk-nixrepo is the culprit there, but you pointed out that that get git rev function won't work in a flake anyway).I was also able to refactor some of the code back out of the
flake.nixand intonix/default.nixadding some arguments and passing thenixpkgsthorough assources.nixpkgs.Some stuff seems to work fine ok on darwin now:
Sadly
nix developdoes segfaults: