Flakify the development shell by aspiwack · Pull Request #507 · tweag/linear-base

aspiwack · 2026-05-12T10:05:40Z

I'm shaving a yak. I've been having trouble with the version of Stack that the shell provides getting older and it not being able to upload to Hackage. And this time I had enough. But the upgrade process is cumbersome with Niv, and so I preferred converting to a flake.

[ETA: this also bumps the Nix and GHC versions; to avoid playing with the flake.lock manually]

Incidentally, this closes #431 . It was time.

aspiwack · 2026-05-12T10:28:35Z

This has implied

A couple of warnings to silence to comply with newer GHC
Bumping Cabal's index state to get new versions of some packages (notable hashtables) which are hopefully compatible with the newer GCC provided by Nix.

aspiwack · 2026-05-12T12:10:58Z

+{-# OPTIONS_GHC -Wno-unused-imports #-}
+
+-- `-Wno-unused-imports`: so that we can import `foldl'` without GHC 9.10+
+-- complaining. Inelegant, but this is just a test file, not the end of the
+-- world.


Not my proudest moment, to be honest.

I'm just wondering why it is part of this PR. Is using flake having an impact here?

Copilot

Pull request overview

This PR migrates the project’s Nix-based development environment from Niv + shell.nix to a Nix flake, while also updating the Stack resolver and switching Ormolu provisioning to come from Nix (addressing the “provide Ormolu via Nix” goal in #431).

Changes:

Replace the legacy Niv + shell.nix dev environment with flake.nix/flake.lock dev shells (including CI-oriented shells).
Update Stack to lts-24.40 and adjust formatting tooling to run ormolu directly (no longer built via stack).
Update CI to use nix develop instead of nix-shell for Cabal/Stack jobs.

Reviewed changes

Copilot reviewed 10 out of 13 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
`flake.nix`	Adds flake-based devShell definitions for development and CI.
`flake.lock`	Pins flake inputs (`nixpkgs`, `flake-utils`, etc.).
`.github/workflows/ci.yaml`	Switches CI steps to `nix develop`-based shells for Cabal/Stack/Ormolu jobs.
`format.sh`	Runs `ormolu` directly instead of building/executing it via Stack.
`stack.yaml`	Bumps resolver to `lts-24.40`.
`stack.yaml.lock`	Updates locked snapshot to match the new resolver.
`cabal.project`	Updates `index-state` to a newer snapshot.
`test/Test/Data/List.hs`	Suppresses `x-partial` warnings in the list tests module.
`bench/Data/Mutable/HashMap.hs`	Adds a module-wide unused-import warning suppression (and rationale comment).
`shell.nix`	Removed (replaced by flakes).
`nix/sources.nix`	Removed (Niv no longer used).
`nix/sources.json`	Removed (Niv no longer used).
`nix/shell-stack.nix`	Removed (Stack/Nix integration now handled via flake shells).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

tbagrel1

I have a couple of questions:

Is it necessary to have two different dev-shell targets ci-<ghc> and ci-stack? It is a bit confusing since per flake.nix, it seems the slack dev-shell target depends on a GHC version parameter, despite not having the GHC version explicitely in its name like the other target.
if we omit the parameters to nix develop, do we still get a

tbagrel1 · 2026-05-12T13:19:34Z

+{-# OPTIONS_GHC -Wno-unused-imports #-}
+
+-- `-Wno-unused-imports`: so that we can import `foldl'` without GHC 9.10+
+-- complaining. Inelegant, but this is just a test file, not the end of the
+-- world.


I'm just wondering why it is part of this PR. Is using flake having an impact here?

tbagrel1 · 2026-05-12T13:26:10Z

+            buildInputs = buildTools ghc-version ++ devTools;
+          };
+
+          ci-stack = mkCIShellFor ghc-version;};


It seems the other ci-shells also have stack in their dep list? Or am I missing something.

In general, I would expect:

shell-cabal-9.6, shell-cabal-9.8, shell-cabal-9.10,..., shell-stack-stackage if cabal shells are not providing/not compatible with stack and vice-versa

shell-cabal-9.6, shell-cabal-9.8, shell-cabal-9.10,..., shell-stackage if cabal shells are not providing/not compatible with stack but the last one allow to work with both cabal+stack

shell-9.6, shell-9.8, shell-9.10,..., shell-stackage if all shells are providing both cabal+stack; with shell-stackage being the default one

I'm not sure the ci- prefix is bringing much here, since I don't think we have different devshell targets for actual developpers?

I called them ci to signify that they have minimal build tools. Whereas the real dev shell has dev tools as well, such as hls. Would there be a better name?

Indeed, I got confused here.

I'm wondering if it wouldn't be better to have these with dev tools enabled by default (conditionned by a switch), and flip the switch off in the CI (to not use the dev tools)

Because when cabal CI breaks, and one wants to see what went wrong and reproduce locally, I guess it may be good to have access to dev tools? That being said, dev tools are currently not indexed by ghc-ver, but by the global ghc-version, so it would require a slightly larger change.

There's no switch in a Flake. Only a list of named shells.
We usually don't want HLS to be present in the CI, it can be a problem (it tends to get rebuilt and stuff). But it's possible to double these shells and make a CI and a Dev version for each. Is it worth it?

I'll let you decide what is the best course of action here.

Having ci shells + dev shells is a bit verbose, but the most complete option while still being efficient

Having only ci shells can be a bit annoying when trying to debug something that breaks specifically in a particular cabal version

Having dev shells only can be quite heavy/annoying in normal circumstances where the CI is not supposed to break ^^ So I guess it's the worst option

I added the dev shells then.

$ nix flake show … └───x86_64-linux ├───ci-910: development environment 'nix-shell' ├───ci-912: development environment 'nix-shell' ├───ci-96: development environment 'nix-shell' ├───ci-98: development environment 'nix-shell' ├───ci-stack: development environment 'nix-shell' ├───default: development environment 'nix-shell' ├───dev-910: development environment 'nix-shell' ├───dev-912: development environment 'nix-shell' ├───dev-96: development environment 'nix-shell' └───dev-98: development environment 'nix-shell'

aspiwack · 2026-05-12T14:29:33Z

@tbagrel1
(there's no thread for the following, for whatever reason, answering here)

I'm just wondering why it is part of this PR. Is using flake having an impact here?

I bumped the Nixpkgs and GHC versions at the same time, by laziness (I should have split it in another PR or something, but it didn't seem important enough). And the consequence is that in newer GHC, foldl' is in the Prelude. Which trigger warnings. But per #507 (comment) I found a less annoying solution.

aspiwack · 2026-05-13T07:10:00Z

Ok, so, most of the shells spent ~20min (which is wasteful, even we got almost all the relevant feedback within 2 min) building Cabal (and Ormolu, but mostly Cabal). I realised (remembered? (stopped being an idiot?)) that Cabal and Ormolu were available at toplevel (and they don't need in any way to be built with the same compiler we install; the toplevel version of Cabal supports all available compilers).

So while it's not the end of the world, it's easy to make the CI much less wasteful. So I did that. Which concludes this session of yak-shaving.

aspiwack force-pushed the flakify branch 3 times, most recently from f8efb57 to 2abbdfc Compare May 12, 2026 10:26

aspiwack force-pushed the flakify branch 2 times, most recently from 03c8069 to 796489c Compare May 12, 2026 12:10

aspiwack commented May 12, 2026

View reviewed changes

aspiwack marked this pull request as ready for review May 12, 2026 13:01

aspiwack requested a review from Copilot May 12, 2026 13:07

Copilot AI reviewed May 12, 2026

View reviewed changes

Comment thread .github/workflows/ci.yaml

Comment thread flake.nix

Comment thread flake.nix Outdated

Comment thread bench/Data/Mutable/HashMap.hs Outdated

Comment thread format.sh

Comment thread .github/workflows/ci.yaml

tbagrel1 approved these changes May 12, 2026

View reviewed changes

aspiwack force-pushed the flakify branch 2 times, most recently from 77539f5 to 2304d9c Compare May 13, 2026 06:40

Flakify

7dd8837

aspiwack force-pushed the flakify branch from 2304d9c to 7dd8837 Compare May 13, 2026 07:04

aspiwack merged commit 1a972aa into master May 13, 2026
13 checks passed

aspiwack deleted the flakify branch May 13, 2026 07:10

Conversation

aspiwack commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aspiwack commented May 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tbagrel1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tbagrel1 May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aspiwack commented May 12, 2026

Uh oh!

aspiwack commented May 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

aspiwack commented May 12, 2026 •

edited

Loading

tbagrel1 May 12, 2026 •

edited

Loading