Add a nix flake - Githubissues

GrammaticalFramework / gf-core

Grammatical Framework core: compiler, shell & runtimes

https://www.grammaticalframework.org

Other

129 stars 35 forks source link

Add a nix flake #165

Open o1lo01ol1o opened 10 months ago

o1lo01ol1o commented 10 months ago

...that allows gf to be built in a composable way. This will shortly be consumed by a flake in gf-rgl that builds using this flake as an input.

Credit to @anka-213 for the overrides and patches needed.

On top of #164

inariksit commented 10 months ago

@anka-213 pointed out that we probably shouldn't have the this as an official part of gf-core, because it ~reverts https://github.com/GrammaticalFramework/gf-core/commit/1294269cd60f3db7b056135104615625baeb528c , which Krasimir seems to have strong preferences against.~ EDIT. nevermind, I misunderstood, this doesn't revert anything, just adds a patch that is only meaningful for nix users.

~Is there a way where Krasimir can keep using his workflow of runghc Setup.hs {configure,build,install} and it works as it does now, but we can also include the changes that @o1lo01ol1o wants to include?~ EDIT. Krasimir can totally keep his workflow, and if I understood correctly, Anka was just worried about the new change being not aesthetically pleasing, and leading to potentially hard to maintain nix code in the future.

anka-213 commented 10 months ago

@inariksit I'm not sure that I'm against having it in gf-core as such, but we should probably change it a bit if we do so. It doesn't actually revert that patch entirely, it just contains a patch file for doing so when using nix, which I doubt would affect krasimir. It's mostly just that having a patch file in the repo like this feels a bit strange

o1lo01ol1o commented 10 months ago

The only way to nix-ify this repo is by separating out the IO process that tries to contact a server. Short of a refactor, applying this patch seems sufficient. Though sub-par from a maintenance point of view since any fix to the repo upstream of the patch will break this flake. Until that time, it seems like a decent way to get gf (and the rgl, wordnet) as system libraries without building each off master manually.

This flake could also live at, eg, flakeshub.com, but that isn't great for maintainability or discoverability.

anka-213 commented 10 months ago

This flake could also live at, eg, flakeshub.com, but that isn't great for maintainability or discoverability.

it actually can’t, since it uses IFD (import from derivation), which isn’t supported on flakehub.

the main two reasons why i put it in a separate repo are

so it’s on a repo i have push permissions on and can more easily maintain and
to collect all the gf-related nix files in one place

but there are definitely advantages with having them directly in the repo. one is that it improves discoverability and makes it more official, another is that it will automatically be kept up to date with the latest version of gf-core

i’ve also considered adding it to nixpkgs, but i haven’t been completely sure how to do that and what structure to use, especially since it’s a programming language and might want to have access to libraries

inariksit commented 9 months ago

Thanks for the discussion and clarifications! So as I said earlier, now that my misunderstanding was cleared, for my part I don't see a problem accepting this PR as is. Just double check that I have understood everything correctly:

Krasimir can keep his workflow now
Everyone using Nix can use this now
In the future, if the code in gf-core changes significantly, the patch that reverts cabal-install may become outdated, and then there will be problems for Nix users
Even if Nix workflow ends up not working (=needing a major refactor), Krasimir and everyone else who installs GF not via Nix can keep their desired workflow in the future

So if those are the facts, I have no problem whatsoever accepting this PR. (Also I would be happy to give Anka push rights to gf-core!)