`build-tool-depends` executables don't have a `.conf` file

[parsonsmatt]

This is a problem that manifests when trying to use haskell.nix. If it sees the build-tool-depends entries, it does try to build them, but then cabal build is unable to see or execute them.

Cf input-output-hk/haskell.nix#839 (comment)

Note that this really isn't specific shellFor, but specific to v2 cabal. You can always use v1-* cabal commands to get the old behavior (see SolveExecutables in cabal code). I think a reason this is coming up recently is that cabal 3.4.0.0 made v2 the default.

The reason this is really difficult is that both Nixpkgs & haskell.nix use the Setup.hs method of configure / install, which doesn't install a .conf file for executable components. I'm not sure if it makes more sense to

See Cabal comment for reference:

build-tools dependencies
NB: Only include these dependencies if SolveExecutables
is True. It might be false in the legacy solver
codepath, in which case there won't be any record of
an executable we need.

I'm unclear whether or not this is a feasible or acceptable approach, and would appreciate guidance on this. @matthewbauer says that we can either

1. "Patch Cabal so Setup.hs method installs executables correctly,"
2. "or try to switch to the new install method." (what is the new install method to use?)

[Mikolaj]

I'm unfortunately very ignorant of Nix. What is your situation? Are you committed to Nix or does the "new install method to use" include something without Nix? Alternatively, I seem to remember Nix people that use the Nix shell to just normally call cabal, presumably including v2- commands. Is that an option for you? Is haskell.nix a must, or only Nix?

[parsonsmatt]

What is your situation?

We currently are running nixpkgs for our main and are trying to transition to haskell.nix as this will allow us to use cabal.project as a source-of-truth.

In the nixpkgs approach, we specify all dependencies in nix, and then cabal build pulls from the nix store for these dependencies.

In the hakell.nix approach, we specify all dependencies in cabal.project or .cabal, and haskell.nix creates a nix-shell from these specifications that builds what we need. This is good because it allows us to have a cabal.project that is always up-to-date with all the version info you need, making nix optional, and for those that want to use nix, they can still have an easier time editing the package files rather than complex nix derivations.

I'd frankly prefer we not use nix at all, but it's a necessary part of our build infrastructure at the moment, and there are no plans on replacing it.

Is that an option for you? Is haskell.nix a must, or only Nix?

The value-prop of haskell.nix is that it creates the nix derivations based on the cabal specifications. SO we can still have a nix-shell build environment with all necessary system dependencies, but we don't need to use nix to manage Haskell dependencies.

As far as I can understand it, the real question is:

Can we make Setup.hs method installs executables with a .conf file?

[Mikolaj]

Can we make Setup.hs method install executables with a .conf file?

So let's focus on this one. Please correct me as I spell this out in my own words. I see the files in my project:

./dist-newstyle/packagedb/ghc-9.0.2/horde-ad-0.1.0.0-inplace-testLibrary.conf
./dist-newstyle/packagedb/ghc-9.0.2/horde-ad-0.1.0.0-inplace.conf

These have been generated by cabal v2-build. From the above I understand Setup.hs neither generates them nor uses them. But v2 both generates them and uses them at least in case of build-tool-depends executables?

So the idea is that haskell.nix would generate the executables with Setup.hs, make the executables and the new .conf files somehow available to the user and then the user would run v2- commands, which need the .conf files?

I suppose, in the best case, it's just the matter of adding a flag to Setup.hs that calls the already existing code from v2- to create the .conf file. In the worst case, the Setup.hs code is deep within the Cabal library and would need to call some code deep within the cabal-install package and would lack tools to create the arguments the cabal-install code needs. Does anybody know which it is?

Could haskell.nix use v2- to create the executables, instead? Why hop between Setup.hs and v2-? They are not supposed to be interoperating and the direction the calls go is always from v2- (and v1- for that matter) to Setup.hs, never back.

[matthewbauer]

Right, the main issue seems to be using ./Setup install on executable dependencies of a v2 project. While it obviously comes up when using Nix, I don't think it necessarily requires using Nix.

From the above I understand Setup.hs neither generates them nor uses them

I don't think that's true. Setup.hs will generate them with ./Setup install, which calls the ./Setup register command:

https://cabal.readthedocs.io/en/3.4/setup-commands.html#runhaskell-setup-hs-register

I think the issue originates from these lines:

cabal/Cabal/src/Distribution/Simple.hs

Line 790 in 76f6d3c

when (hasLibs pkg_descr) $ register pkg_descr localbuildinfo registerFlags

cabal/Cabal/src/Distribution/Simple.hs

Line 805 in 76f6d3c

if hasLibs pkg_descr

Since with v2- we do want to register even if there are no library components.

Could haskell.nix use v2- to create the executables, instead? Why hop between Setup.hs and v2-?

That's possible. Might be worth asking haskell.nix if that would work. I actually didn't realize there was a v2-install until today. I wonder if any other package managers are using v2-install to package haskell.

[Mikolaj]

Since with v2- we do want to register even if there are no library components.

Oh, right. If Setup.hs thinks exes don't need to be registered, that could be fixed and there should be no harm in doing so. I wonder if Setup.hs knows how to register exes (is that only about build-tool-depends exes?). Have you tried changing these conditions by adding an alternative with hasExes and building a package with such a version?

I wonder if any other package managers are using v2-install to package haskell.

That's quite possible for package managers (e.g., the HomeBrew one) that don't package Haskell libraries but just build exes from Hackage and package those, which is a very sane thing to do. Otherwise, v2-install is problematic, because in v2, generally, libraries are not supposed to be installed globally. There are methods and workarounds for that, but they are second class. However, Setup.hs is third class. :) Or rather very low level.

[ParetoOptimalDev]

Could haskell.nix use v2- to create the executables, instead? Why hop between Setup.hs and v2-?

Because if I have a haskell.nix project using a build tool like hspec-discover I would rather nix do the building.

I'd rather nix do the building because it will likely skip building entirely and download the prebuilt cached hspec-discover binary from cache.nixos.org or my cachix binary cache.

The problem is cabal v2 won't trust the nix built hspec-discover as a build tool.

From my perspective it seems either:

• cabal needs to give a way to trust executables it didn't build
• haskell.nix has to keep hacking around this and having bad UX and interoperability with cabal for build tools

I hope it's not the second, because then cabal.project can't be a source of truth for Haskell.nix.

[ParetoOptimalDev]

Something that may clear up confusion:

• bootstrapping Haskell toolchain and installing haskell packages are done by nix
• development is done in nix-shell with the nix bootstrapped environment and cabal v2 commands
• cabal should install no haskell packages because Nix should have already bootstraped them

This issue is about that last point being true for buildTools.

[Mikolaj]

I see, so it's nix that installs packages globally, and to v2 they look like just a bigger set of packages bundled with GHC, so it knows how to handle that. Except that the bundled packages (libraries) are never used as build-tool-depends (exes). BTW, when you are currently generating the build-tool-depends exes with Setup.hs, are they placed on the path (by Setup.hs or by haskell.nix)? In fact, I don't remember if the registering done by Setup.hs applies to executables at all. IIRC, v1 (which is close to Setup.hs) just copies exes to bin/ and does not enter them into any packagedb.

@gbaz: you have an intimate knowledge of these things; how hard would it be to teach v2 to use any random executables in path for build-tool-depends (preferring the just built/registered exes, if v2 can tell at all)? Alternatively, could Setup.hs do any registering of the exes, if that's needed (.conf files, etc.)? Is that a security issue (a trojan in path posing as a build tool) or just a tweak needed in the code?

[ParetoOptimalDev]

@Mikolaj Is there a deprecation plan for cabal-v1?

The current best work-around for using Nix correctly in the workflow where Nix provides packages and build-tools is to use cabal-v1.

haskell-language-server is also affected here because a project that uses something like hspec-discover will cause cabal to go and install the hspec-discover binary even though Nix has already installed it.

I suppose I could send a patch to haskell-language-server to follow cabal-v1 when it comes to build tools but that feels very much like going backwards.

I feel uncomfortable basing my workflows on cabal-v1 and fear in the future I'll be forced away from using Nix with Cabal.

I saw an interesting proposal in #4646 about getting Nix and Cabal to cache dependencies in a way where each is compatible with the other:

One goal in that regard is that Nix and Cabal should be able to hash files in the same way. I think the best thing to do is teach them both git tree hashes. Once we reach the point where hackage builds, patched hackage builds, and local builds are all cached with comparable keys, things will start to move smoothly. - @Ericson2314

That sounds quite ideal, maybe that's worth opening an issue on for wider discussion?

Edit: I also see a proposal for Build Drivers that could help this issues, but I don't fully understand everything yet: #7906

In any case, thanks for your help 🙂

[Mikolaj]

@Mikolaj Is there a deprecation plan for cabal-v1?

The only plan I know of is shutting down the lights in a major version release. Which is why we are not keen on doing that until somehow the world sorts itself out (people's workflows update, v2 supports more of v1, etc.). Semi-maintaining v1 costs something, but so far not so much as justify harsh solutions IMHO.

haskell-language-server is also affected here because a project that uses something like hspec-discover will cause cabal to go and install the hspec-discover binary even though Nix has already installed it.

Is that a real problem? Afterwards cabal knows about the binary and will not (often) install again.

I saw an interesting proposal in #4646 about getting Nix and Cabal to cache dependencies in a way where each is compatible with the other:

Yes, that looks fine and the other tickets you linked, as well. Unfortunately, lately we have quite many valuable public discussions and comparably few actual implementations. If there was a party committed to implementing a particular feature then the relevant discussions would be a much better use of our scarce resources, I'm very much open to imperfect designs and implementations that scratch a real itch and are maintained by users, but not so much to public debates of universal solutions. We just don't have the resources.

[ParetoOptimalDev]

Is that a real problem? Afterwards cabal knows about the binary and will not (often) install again.

Arguably no, but I'll list a few issues:

• I can't just forget about the "provide haskell toolchain" aspect of things
• I have to worry implications of and differentiate between Nix installed Haskell dependencies and Cabal installed Haskell dependencies (maybe I could just not worry? 😅
• If I delete my cabal store for whatever reason, I can't quickly get back to work like binary caching from Nix would allow me to
• I've had these build-tools take 30-60m before, and I never know when that may happen so it feels unpredictable since my focus is on making sure Nix has already provided haskell dependencies.

I'm very much open to imperfect designs and implementations that scratch a real itch and are maintained by users, but not so much to public debates of universal solutions. We just don't have the resources.

I very much agree with about imperfect designs and implementations being more valuable than public debates of universal solutions.

I want to pull the trigger and try either directly patching cabal-v2 to allow Nix to provide it build-tools or perhaps, trying to implement the likely more ambitious shared caching between Nix and Cabal.

My fear, and perhaps the fears of others, is putting work into a patch and then the contribution not being found acceptable.

Is there a best practice for avoiding this? Should I create some issue like "RFC: Allow cabal-v2 to trust build-tools from Nix" and state my intentions to work on that if no one disagrees?

My other looming fear I haven't touched on is that it feels like there is some resistance to integrating better with Nix. Challenging that feeling though:

• nix integration was worked on and merged before
• cabal-v2 itself takes inspiration from nix with nix-local builds

So perhaps my fears are unfounded and I would even be okay with just trying to hack on Cabal to allow it to trust build-tools?

In the spirit of respecting scarce resources I'll say that I would have made this response shorter if I had the time 🙂

[Mikolaj]

but I'll list a few issues

Fair enough. At the very least, for reproducibility and curbing chaos, it should be clearly delineated which parts of the "haskell toolchain" cabal takes care of and which Nix does.

I want to pull the trigger and try either directly patching cabal-v2 to allow Nix to provide it build-tools or perhaps, trying to implement the likely more ambitious shared caching between Nix and Cabal.

Go for it!

My fear, and perhaps the fears of others, is putting work into a patch and then the contribution not being found acceptable.

Some, though not all, features can be maintained as separate tools (see https://github.com/phadej/cabal-extras or cabal-plan). This is actually a very good way of starting the development process, regardless if and when they get merged into cabal proper or advertised in cabal manual or release notes (we should do that more often).

Should I create some issue like "RFC: Allow cabal-v2 to trust build-tools from Nix" and state my intentions to work on that if no one disagrees?

Yes, please do, even if that's going to be an external tool (no idea if that makes sense).

resistance to integrating better with Nix

I think the fight has gone out of us. ;D Expect no fierce resistance.

Seriously, though, there is certainly some duplication of functionality there, with the accompanying maintenance effort whenever the functionality in questions changes in GHC and/or cabal. So the extent to which we duplicate needs a pragmatic justification (not just noble causes, like "every binary should be cached" or Debian's "every library should be shared"; we see where this leads) and a plan for future maintenance. I'm sure we never had a problem with Nix, only with the natural scenario of abandoned volatile features we don't understand, but we eventually need to (un)maintain. I'm sure we can sort it out in a ticket.