Overriding snapshot's c2hs

[mwu-tow]

I have a package that needs c2hs 0.26.1 tool to build. It has to be exactly 0.26.1, the 0.25.2 won't work. The package is built with GHC 7.8.4 (using lts-2.22).

With cabal it simply works when I have a good c2hs in PATH. However with stack it is not so simple — the PATH one gets overriden with /home/mwu/.stack/snapshots/x86_64-linux/lts-2.22/7.8.4/bin/c2hs that is, as per resolver, 2.25.2. It is an artifact from previous unrelated builds — if I hadn't previosuly built a c2hs (or package depending on it) with this resolver there wouldn't be a problem.

Can I make it somehow work by editing stack.yaml? The issue is that c2hs belongs to Build-Tools and not to Build-Depends. Therefore listing c2hs on extra-deps won't do anything (it is not a dependency and will be ignored) and placing it in the packages list will create a race condition (build will succeed if proper c2hs installs before my package is configured).

Can I define in stack.yaml exact build tools versions to be used (and setup by stack)?
Would it be possible for stack to treat build-tools like dependencies when handling extra-deps?

[sjakobi]

Seems related to #593.

[borsboom]

I don't think this is currently possible. A tricky part of implementing support for this is that we rely on the GHC package databases to keep track of which packages are installed, but executable-only packages like c2hs don't get an entry in the package database. This is a common source of frustration, which means it's probably worth tackling in Stack. Stack would need to add its own way of tracking executable-only packages, and we'd probably need to make some adjustments to the way .cabal files' build-tools are handled.

@snoyberg, I'd value your opinion.

[mboes]

Cc'ing @mietek, who had worked around this very issue of executable only packages not being tracked in Halcyon.

[snoyberg]

We do track installation of executable packages in Stack. What happens if you add the desired version to extra-deps and then explicitly build with Stack build c2hs?

[mwu-tow]

@snoyberg
When I add desired c2hs version to extra-deps and issue stack build c2hs it does build and install c2hs to the local database. That's actually relatively good workaround for my problem — first prepare c2hs then do actual build.

Installing c2hs does not seem to create entry in package database but if I run stack build c2hs twice, the second run does nothing, so stack must know that it is installed.

As for tracking executable packages — I believe that Cabal just calls the program on PATH, ignoring whether the package was installed or just the executable was copied from another machine. This sometimes cause problems, as the executables can rely on build artifacts that are installed with the package. [I believe it is the case with haddock — if I delete packages directory leaving the executable intact, Cabal will accept it but the process will fail later, as haddock will be unable to find its templates or sth.]

There's also one more thing — not sure if stack should support it but I think it should be mentioned. Cabal package description allows version bounds for build tools. They are however not "resolved" — they are just used to fail the configure step if the constraint is not met. Question is what should happen when constraints on buildtools are inconsistent, e.g. stack.yaml builds package A requiring build-tool c2hs==0.26.2 and package B requiring c2hs==0.25.2.

• seemingly, since c2hs is "just" an executable, stack could build both versions of c2hs and then run Setup.hs with path to the appropriate one. However, as this requires installing two versions of the same package it would need to be done to different databases (perhaps even creating databases just for c2hs) so it is likely more trouble than it is worth.
• what if Cabal library in configure step checked all the executables visible in PATH and picked the one with the right version instead of the first one? From my experience people usually have the numerous versions of tools installed here and there and the "good one" often gets accidentally shadowed.
• if build is impossible because of conflicting tools version, it would be nice if stack could at least detect such situation and fail the build immediately, giving sensible diagnostics.

[snoyberg]

Especially given the changes to how build tools are handled in Cabal 2.0, I'm going to close this issue. I don't believe there is any change we can reasonably make to Stack's handling here. If you depend on a specific version of a build tool, it should appear in the stack.yaml file (directly or indirectly). Additionally, with extensible snapshots, you can create a customized snapshot which excludes the c2hs version in the parent snapshot.