-
-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide Nix expressions #1110
Comments
Please excuse my ignorance here, but:
|
Let me try to answer some of @garyverhaegen-da’s questions and hopefully @domenkozar can weigh in on the others:
I haven’t given this too much thought so far but atm I’m leaning towards doing |
They make up for deterministic installation of ghcide on linux and macos. No matter which environment or distribution someone is using, it's always going to work. Binary caches (cachix) provide binaries to avoid compilation from source, making the whole installation a matter of downloading ~100MB binaries and unpacking them. This is convenient if you want ghcide-ghc865, ghcide-ghc864 ... ghcie-ghc841 Nix is just a build tool here, Haskell dependencies are mapped 1-to-1 from stack.yaml plan.
It's quite prevalent, although I have no numbers to back that off. At most Haskell hackathon there's a group of people hacking on Nix tooling. The benefit is that it simplifies the installation of ghcide, which is one part of why is editor integration hard in Haskell compared to the rest of the languages.
I see no other costs rather than maintenance.
It's using GitHub apps, so you grant access via GitHub to a single repository and tie that to a token which agent uses to run jobs.
Both are written in Haskell and other boring technologies, so the confidence is pretty high. So far there were a few downtimes, mostly handled within an hour or two. Cachix is older though, more than 1000 people rely on it. Hercules CI has over 100 users, growing each day. I'd like to also add that we're going for the commercial success of Nix, so I am biased here. I don't think you need to do any of the infrastructure if you don't want to. I'd be OK just maintaining Nix expressions myself in ghcide and giving access to our CI to build it. I used to maintain https://github.com/Infinisil/all-hies for HIE itself, and people really liked the simple installation method. No hard feelings if you decide to go a different route, it would be just less maintenance for me having all of this upstream. |
To clarify, any change of infrastructure, including a move to an external CI or the addition of a webhook, needs to go through an audit by our security team. So I'm very keen on getting as much value as we can without doing that. From the above, it seems to me that we can achieve almost all we want by simple changes to our existing build process and not introducing any new credentials: having the nix expressions in this repo, building them as part of CI, and keeping a cache of
The only downside left would be that nix users would need to build those expressions instead of being able to download the binaries. Am I understanding correctly so far? If the only missing piece after that is the discovery of new commits by Hercules so it can pre-build packages, could it just poll this repo, say once a day? That way we would not need to know about it: no credential, no webhook, no external service we need to know about, and therefore no need to go through a security audit. |
Let me summarize the current state: We’ll happily accept the nix expressions in this repo with an Azure-based CI setup but relying on an external service is not something we want to do right now. |
That's the very first thing one would do, but it brings a bunch of problems:
Either way it seems like you've made the decision so I won't dwell on this further, let's go step by step. I'll prepare expressions to be upstreamed here. |
The way azure caches work, this shouldn’t ever grow. Downloading the closure should be relatively fast (we have a significantly larger closure on the |
Regarding the nix cache, we do something similar for the daml repo, it may be worth taking a look. Essentially, the cache is recreated from scratch every time the files that define it (in this case it would be the set of nix expressions) change, which hopefully doesn't happen too often. I guess this counts as GC, in a very naive way. |
Is this still being considered to be merged into the ghcide repo? |
Right now, no. I think it’s fine for this to be in a separate repo. |
They currently live in https://github.com/hercules-ci/ghcide-nix, however, this has a drawback that they have to be manually updated and thus can't use just any commit from ghcide and get a binary.
Once Nix files are in place here, I recommend setting up CI to provide binaries for each commit:
The text was updated successfully, but these errors were encountered: