Support for `run-tool-depends`

[Ericson2314]

build-tool-depends is for for executables used when building a component. run-tool-depends is for executables used when running a component. [Library ones are propagated to the final executable.] This distinction is important for build-time parallelism: the executable need not be built before the thing that needs it, garbage collection: installed things don't need their build-tool-depends but do need theirrun-tool-depends, and cross compilation: the former is built for the build platform while the latter is built for the host platform. [for reference, regular libraries are built for the host platform while plugins/TH should be built for the build platform.]

The motivating example would be for Setup.hs and #4648. But I think special-casing Setup.hs is not needed when the same principle can applies to any component.(likewise I sometimes wish we had build-depends for the custom setup stanza not setup-depends for consistency.)

For the cross stuff, recall that the Setup executable is built on the build platform for the build platform, so it's host and build platform (as opposed to that for the rest of the components) are the same. That removes the build-tool-depends and run-tools-depends distinction for cross for custom setups, but still keeps the others.

[harpocrates]

Haddock would benefit from this too. There are some test suites (see ‘html-test’) that have ‘haddock’ in their ‘build-tool-depends’. This is all fine as long as these suites are run with ‘new-test’, but as soon as you want to manually ‘new-run’ the test suite (for instance to pass extra arguments), the right version of GHC and the Haddock executable need to be manually passed in.

[hvr]

@Ericson2314 just to be clear: run-tool-depends would only be allowed in the 3 stanza kinds:

• test-suite
• benchmark
• custom-setup

?

PS: IIRC we had some discussion somewhere in the issue tracker already about how to be more exact regarding dependencies along various axes such as TH, run-time, compile-time, host/build etc

[hvr]

@harpocrates The $PATH mechanism is utterly inadequate for locating the currently used GHC executable (relying on that would catastrophically break for virtually all build environments I use); we'd rather need to design an env-var based communication protocol to inform testsuites et al which GHC executable has been used by the current build-env.

As for cabal new-run test:... not emulating the environment of cabal new-test; I consider this something we need to fix in cabal new-run and special case cabal new-run test:... and cabal new-run bench:... to be more compatible with their cabal new-test and cabal new-bench counter-parts.

Consequently, the proposed run-tool-depends would merely provide a (desirable) optimization for haddock's use case for specying the depedency relation & locating the intra-package component haddock, but would do nothing for locating the proper GHC version as that needs to be handled differently anyway (and there's also some cyclic weirdness involved cause haddock happens to be a wired-in build-tool cabal knows about and probes for on startup...)

[Ericson2314]

@hvr, we can start with just those three. I think it is well defined for the rest but there is no impending need.

That discussion was in a thread linked from the setup-tool-depends thread. I'm on my phone or I'd link it here myself. Pretty sure this is in line with that. It's #4104 (comment)

I don't think GHC is too weird a case. I think of all components as having an implicit build-tool-depends: ghc.

I'm not up to date on how new-run and new-test work, but in general components should not have access to build-time dependencies like build-tool-depends when they are run. A matching run-tool-depends should also be needed. This rigidity is necessary to ensure cross also works.

[hvr]

@Ericson2314 well, the problem with build-tools-depends: ghc is that it simply won't work -- in fact, all such packages would be flagged as failed on matrix.hho due to the way the environmnet has been set up there to be intentionally hermetic.

As for the the rest of the cases (besides the components I mentioned), I don't think they're well-defined at all. Since we have no control over the post-installation setup (since we're not NixOs); and it'd be rather misleading to state a "run-time dependency" when we don't have enough to control to actually guarantee that. That's why I asked whether run-tool-depends was only intended to be limited to those cases where we actually control the environment of execution. And don't get me wrong; I am very sympathetic to give us a more exact way to specify whether a tool is required during compilation-time (via build-tool-depends) or whether it suffices if it's available after compilation, when new-run/new-test/new-bench (for executable & benchmarks) or during Setup.hs-invocations (when specified for the custom-setup pseudo-component).

[Ericson2314]

OK I accept that given what Cabal/cabal-install actually do, executable and library run-tool-depends can't be meaningfully implemented. That's fine.

I guess build-tools-depends: ghc is the same to me in that I think it conceptually makes sense but Cabal wouldn't know what to do with it either.

[hvr]

@Ericson2314 btw, we actually have a related concept, scope: private which is about treating executables in a package as "package data" for code to invoke; so in the nix-style store paradigm we do have a concept of "runtime dependencies"... unfortunately scope: private is currently broken when per-component is active as we have no way to locate the binaries...

[nomeata]

I came here looking for a reliable way to have a cabal project with two cabal packages foo and bar with executables of that name, where bar needs to have foo in the $PATH. Guess a run-tool-depends: foo stanza in bar’s executable section would be expressing that, right?

[Ericson2314]

@nomeata yup that sounds right.

[hvr]

@nomeata more like run-tool-depends: foo:foo IMO :-)