[RFC] Add 'cabal new-path' command

[DanielG]

Since a lot of 'new-*' commands are still missing I keep having to fiddle around with hard-coded paths in projects where I use new-build, so I though why can't Cabal have a command that tells you all those tedious internal paths (like Stack).

This is really just a quick prototype to get feedback, so what do you guys think?

[mention-bot]

@DanielG, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ttuegel, @23Skidoo and @dcoutts to be potential reviewers.

[23Skidoo]

Seems like a good idea to me.

/cc @dcoutts

[23Skidoo]

Related: #3643.

[DanielG]

Not sure why the build is failing for SCRIPT=bootstrap but not for anything else, any ideas?

Main.hs:81:1: error:
    Failed to load interface for ‘Distribution.Client.CmdPath’
    Use -v to see a list of the files searched for.

[ezyang]

It's because you didn't add the new module to the Cabal file.

[ezyang]

More substantive comment: this somewhat overlaps with information you can get from plan.json, right? Would it make sense to move all of this to plan.json and document more heavily what keys are available, or maybe there is a place for a way to interrogate for a specific value without having to parse the output subsequently?

[DanielG]

Oh, whoops.

I would very much like to not have to go though a json parser to get this stuff out of cabal. One of the main motivations for me sit down and implement this is to be able to use it from shell scripts and such.

As I said this is just a prototype to discuss if this is a thing we want to add. I would certainly add more options to extract specific fields rather than just dump them all if we decide to do that.

[ezyang]

Yes, that's what I was alluding to at the end of my comment. If you're specifically interested in grabbing these values for shell script, you probably don't want a pile of colon separated paths; that's less convenient for command line use? (But maybe you also want to avoid repeatedly calling cabal new-path to keep things snappy?)

In any case, designing a CLI interface like this involves a large degree of taste. My feedback is:

1. Yes, this is useful. (And especially useful since we still don't have new-run/new-test/etc)
2. Decide if you want people to call this command once, or use it like $(cabal new-path foo-0.1 distdir)/build/blah/blah in their build scripts. If they're calling the command once, what is the most convenient way to make use of the parameters from a shell script.
3. In terms of implementation, whatever this is should actually look quite similar to the implementation of new-run (for example). I don't think hacking it with filter is the correct long-term path. It would be great if it could take advantage of the refactor from Rework build target handling #4179, but if you want this patch done in any reasonable time you'll probably have to commandeer that patchset (go for it!)

[phadej]

I played with this a bit: https://github.com/phadej/cabal/tree/danielg-new-path

I hope I'll have time today to clean up the impl, but the idea that

cabal new-path --path-element bin-dir

would output only single line which can be used in shell scripts. I.e.

for testexe in $(cabal new-path --path-elements test-executables); do $testexe; done

---

Side-comment: the command line parsing lib is quite not-for-human-beings :S

[DanielG]

I think this fell too far behind, probably easier to start from scratch.