Unnecessarily difficult to run executables from outside of project

[bgamari]

Describe the bug
One thing that I have noticed holding me back from using Haskell in script-like applications is the difficulty of using Cabal-packaged executables from a working directory outside of the project where they live.

For instance, consider that I have a simple single-file Haskell executable, Frobble.hs with no dependencies. I can run this program using with runghc /path/to/frobble/Frobble.hs from any directory that I please. If I want I can even just chmod +x the source file and add an appropriate hash-bang. All is well with the world.

Then one day I want to add a dependency to a Hackage package. Being a good cabal-install user, I create a frobble.cabal with an executable frobble stanza. However, I have now lost any ability to conveniently run my program from outside of the directory containing the .cabal file. As far as I know, my only options are:

• $(cd /path/to/frobble; cabal build frobble >&/dev/null; cabal list-bin frobble)
• using cabal run's hash-bang support, requiring that I duplicate my build-depends in my .cabal file as well as Frobble.hs

There are also a few non-solutions that I have encountered:

• using the --cabal-file=/path/to/frobble/frobble.cabal flag, which seems not to work at all from outside the project directory
• using the --project-file=/path/to/frobble/cabal.project flag, which also does not work

Surely we can do better than this.

Proposed feature

One can think of many possible designs to address this UX shortcoming but these seem the most plausible:

• Teach cabal run to accept a --directory=... flag, telling cabal to pretend it was run from the given directory. This would address the above use-case with cabal run --directory=/path/to/frobble run
• Allowing the user to use a #!/usr/bin/env cabal hash-bang in a source file without providing a {- cabal run: ... -} comment. In this case cabal would look for a .cabal file in the current directory and use the executable stanza with a main-is: matching the name of the invoked source file
• As a more explicit variant of the previous design, allow use of a hash-bang and introduce a syntax in the {- cabal run: ... -} block to allow the user to specify the name of the executable stanza to use (as well as, possibly, the relative path of the cabal file?)

[jneira]

using cabal run's hash-bang support, requiring that I duplicate my build-depends in my .cabal file as well as Frobble.hs

Hi, it would not invalidate the issue for other use cases (several modules?) but could not you take ride of the .cabal file and use only Frobble.hs with the inline comment and cabal run /path/to/Frobble.hs?

[fgaz]

using the --project-file=/path/to/frobble/cabal.project flag, which also does not work

Could you try with #7749 applied? That's a known bug

[ulysses4ever]

cabal run frobble --project-file=/path/to/frobble/cabal.project works for me with cabal 3.8 if the path is absolute. Support for relative paths is pending in #7749 afaiu. @bgamari is it good enough?

--cabal-file probably misled many people: according to discussion on #6880, it's not meant for anything useful currently and should be removed.

[andreasabel]

Me too. I am experiencing the hardship of the OP when migrating a tool from cabal v1 (which has a fixed location for the produced executable) to v2 (which makes it difficult to locate the produced executable and thus suggests cabal run), see agda/agda#5269 (comment).

I support the proposal for a --directory options, which has pretexts in make (make -C dir) and stack (stack --cwd dir). I raised this proposal in:

• Option giving the project root directory #8037

[fgaz]

Why isn't --project-file enough?

[andreasabel]

Why isn't --project-file enough?

Because there might not be a project file.
I prefer not having a project file if it does not say more than packages: . because then I have another configuration file I have to browse (to make sure it does not contain any unexpected configuration).
Also, an empty cabal.project isn't the same as having none, so I cannot simply touch cabal.project to satisfy option --project-file.

[cydparser]

I've implemented option one in PR #8454

Please feel free to discuss/bikeshed in the PR.

[Mikolaj]

Could I ask for help reviewing the PR fixing this issue (#8454)? Even a cursory look and a comment whether this might fix your use case (bonus points for checking out and confirming) would be very much appreciated.

[Mikolaj]

A new proposal dropped at #8454. Could you kindly voice your opinion?

[andreasabel]

#8454 does not seem to implement cabal run --project-root=....
Ah but cabal run --project-dir=... seems to work.

So then let us considered this issue resolved in 3.12.