Feature: info command

[ghost]

A universal cabal info WHAT would be useful to have, and is especially useful for nix-style builds, where the directory hierarchy is deep, parts of it are volatile, and therefore not as straight-forward to guess/type from memory. To be clear, I'm aware of the existing info command.

The motivation was to get the path to where the executable built is stored like this:

$ cabal info bindir

In this specific case we could create an easy to remember symlink for navigating to where the artifacts are, but that raises many implementation questions, and cabal info bindir isn't the only imaginable ui to expose this way.

I've discussed this somewhat with @ezyang, and this is a summary of the conclusion.

[ezyang]

See also #3643. Another name might be cabal paths in reference to stack paths. But it is not so easy to say what the semantics of this command should be. Here are some of the issues:

1. You say cabal info bindir should give a bindir containing executables. Executables of what? A project? A package? (If a package, how do you know which package's bindir you want?) To make matters worse, with per-component build each executable in a single package gets a separate bindir.
2. Suppose that we decide there's a project global bindir which we copy executables into after we finish building them. But there are multiple build trees; e.g., a build tree for 7.8 and a build tree for 8.0. Does that mean there's a separate bindir for each build configuration? Then info must accept all the same flags as new-configure/new-build so that it can tell which build configuration is being used. Should there be a totally global dist-newstyle/bin? If so, what binaries should it point to? (The last thing you built? But what if you didn't build everything? How about the on-disk configuration? A little surprising!) For a related issue see [nix-local-build] new-install interface for installing executables #3332.

[ezyang]

Re milestoning, I think something which solves the problem "where's my executable" needs to be in before we can make new-build default. But there are many roads to Rome; which one to take?

[ghost]

Instead of polluting the namespace with cabal paths and similar query commands I think having paths be a parameter to cabal info makes more sense.

[phadej]

I unmilestone this. There's cabal-plan list-bin to solve where's my executable problem, and someone have to take ownership of cabal info issues. There's huge design space and a lot of colors to pick.

[ghost]

I'm fine with closing this.