Community Survey: Removing cabal's nix integration

Announcements
#1

Hi everyone,
The Cabal team would like to ask our users if anyone would object to the Nix Integration being removed (following a reasonable deprecation cycle).

It has been reported to us that the feature is non-functional, misleading and the documentation lacking. Moreover, and that it is the wrong solution to the problem of using Nix + Cabal, which can be tackled with more modern tools (like flakes) and better knowledge (like Haskell - NixOS Wiki).

Are there users out there whose workflow depend on it? If yes, please express yourselves, because we need to know that you exist before taking further steps.

22 Likes
Is it worth switching from Stack to Cabal?
#2

I don’t know anything about cabal-nix integration, however I use stack-nix integration and planning to migrate cabal. Are cabal and stack migrations similar? If so might workflow will depend on it when I manage to migrate.

#3

I haven’t used it myself ever, but it would be useful to have a way to get cabal to use prebuilt Nix dependencies for e.g. cabal shebangs or other lightweight contexts. But I’ve thought about writing a separate tool to do this.

One thing that’s kind of weird about a good implementation here is that cabal would have to determine the ghc version in this.

#4

I agree it should be removed. What the integration does is trivial to achieve and it’s not very much in the spirit of nix anyways.

1 Like
#5

As one datapoint: In the last 5 years I have been following Haskell and Nix stuff (and communication channels) quite closely, giving a lot of support to people with a wide variety of Nix + Haskell problems. I have learned about this feature for the first time reading this post. So either it is working absolutely smoothly or its user base is very small.

No clue if my observations are representative, though.

10 Likes
#6

I tried to use it on two separate occasion, I never managed to achieve my goals.

I think it’s a good idea to make cabal leaner.

#7

It would be great if somebody could describe what the Cabal’s nix integration does.

The linked docs don’t say, only how to enabled it, not what happens then.

Stack’s docs make it clear what happens with Stack’s Nix integration:

When integrated with Nix, Stack handles Haskell dependencies as it usually does and the Nix package manager handles the non-Haskell dependencies needed by the Haskell packages.

and how exactly it does it:

With Nix integration enabled, stack build and stack exec will automatically launch themselves in a local build environment (using nix-shell behind the scenes). It is not necessary to run stack setup, unless you want to cache a GHC installation before running a build.

Does the Cabal-Nix integration do the same?

Without knowing that, it’s difficult to judge whether something valuable would be lost if this integration was removed, or if it has current shortcomings.

6 Likes
#8

It is my experience that Nix works best as the outer layer, providing the environment and any native dependencies. I’ve never used cabal-install’s Nix integration and I don’t expect to need to.

6 Likes
#9

Actually I believe they do say what it is (supposed) to do, except it’s written under the “Enabling…” heading.

My understanding of what’s written there is that cabal-install should just effectively reexec itself in a nix shell if a package has a shell.nix or default.nix in its directory, which must already be unpacked.

I don’t want cabal to keep up with the latest developments in Nix (what about flake.nix?), this is easily solved with direnv or friends, and using nix-shell directly is far less magical in the first place. I’m in favor of deprecation and removal.

8 Likes
#10

I haven’t used Cabal’s nix integration all that much yet, but it’s broadly similar to Stack’s which I use all the time because I’m on NixOS and Stack isn’t able to install a compiler that runs on NixOS unless you enable nix integration.

Also, it’s much more pleasant and convenient to be able to use cabal or stack directly instead of having to remember to enter a nix shell first, or use nix-shell --run 'cabal ...' or nix-shell --run 'stack ...'.

As others have pointed out, the big advantage of using nix is being able to pin and install native dependencies, since Cabal and Stack provide no help with that beyond checking that the dep is present on the system at build time. Some packages address that by vendoring an entire C library into the source tree, but iMHO that’s a very substandard solution since it involves code duplication, maintenance overhead, and the potential to miss out on security updates.

So I would be in favour of keeping Cabal’s nix integration, assuming that the maintenance burden isn’t too great, and I don’t see why it would be.

1 Like
#11

A related thing that concerns me is that nix’s support for building Haskell projects still depends on the v1 functionality. This seems like a ticking time-bomb to me.

With v1, you can enter a nix shell or a nix package build and provide Haskell dependencies through nix so that Cabal doesn’t need to download and build them afresh. Cabal v2 onwards, however, doesn’t see these packages, even though they show up in ghc-pkg list.

1 Like
#12

I agree with you (I use stack with nix enabled to deploy to nixos). However, maybe a thin wrapper can made (common to stack and cabal).

#13

I don’t know if you’ve already done so, but if you haven’t then I would suggest also posting this to the Nix discourse (https://discourse.nixos.org) since it touches both Haskell and Nix.

2 Likes
#14

I’ve never used Cabal’s Nix integration. I just use this Nix flake template by Serokell for all my Haskell projects and it’s been working incredibly well.

#15

Another user who has been using Nix + Haskell w/cabal for years, and while vaguely aware of this integration, I’ve never found any reason to use it. If this is all it does:

If the package (which must be locally unpacked) provides a shell.nix or default.nix file, this flag will cause cabal to run most commands through nix-shell.

…I don’t think I’d ever use it. Granted, that’s because I use direnv and flakes to automatically put myself into a nix shell when I cd into project directories–but this seems more appropriate to me, vs. cabal having awareness of nix-shell for some reason.

To me this seems like a feature that inverts the relationship between nix and cabal. Seems like a waste of time for cabal to support this, especially given how much nix usage is a moving target, and how much variation there is in how folks use it.

5 Likes
#16

I made a quick PR Add deprecation warnings to Nix integration by yvan-sraka · Pull Request #9205 · haskell/cabal · GitHub that labels the feature as deprecated :slight_smile:

6 Likes
#17

I used it in the past, but haven’t done so for a few years now. I think nix providing an environment in which cabal finds things it can use is the right direction for information flow, and I prefer that cabal be agnostic as to how those dependencies are made available.

5 Likes