"cabal paths" command

[headprogrammingczar]

A common question in #haskell on freenode is where package files are located. It varies by OS and by which database a package is installed in.

Something built into cabal that lists the current global, user, and sandbox directories would make this question much easier to answer.

[ezyang]

I think this is fine. But do you want the output to be machine parseable or not? Note also that internally, Cabal supports an entire stack of package databases so it's not necessarily just three, it could be many. Also which database you're using will vary depending on if you're using build versus new-build, so maybe it should be an extra command flag?

(Just a friendly note: we're experimenting with the pr-welcome tag as a "This feature is fully specified. So if there are still bits of the spec to hash out, we don't want to put the tag on the ticket yet. Once it's hashed out, we can update the ticket description and add the label!)

[23Skidoo]

cabal info seems to be the logical place for this.

[phadej]

imho such command should list what cabal would use, e.g. if not configured then it will list defaults,
if configured then that information and so one.

---

% stack path
Run from outside a project, using implicit global project config
Using resolver: lts-5.17 from implicit global project's config file: /Users/ogre/.stack/global-project/stack.yaml
stack-root: /Users/ogre/.stack
project-root: /Users/ogre/.stack/global-project
config-location: /Users/ogre/.stack/global-project/stack.yaml
bin-path: /Users/ogre/.stack/snapshots/x86_64-osx/lts-5.17/7.10.3/bin:/Users/ogre/.stack/programs/x86_64-osx/ghc-7.10.3/bin:/Users/ogre/.local/bin:/usr/local/heroku/bin:/usr/local/bin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/usr/local/sbt/bin:/Users/ogre/Library/Haskell/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/Users/ogre/.rvm/bin
programs: /Users/ogre/.stack/programs/x86_64-osx
compiler-exe: /Users/ogre/.stack/programs/x86_64-osx/ghc-7.10.3/bin/ghc
compiler-bin: /Users/ogre/.stack/programs/x86_64-osx/ghc-7.10.3/bin
local-bin: /Users/ogre/.local/bin
extra-include-dirs: 
extra-library-dirs: 
snapshot-pkg-db: /Users/ogre/.stack/snapshots/x86_64-osx/lts-5.17/7.10.3/pkgdb
local-pkg-db: /Users/ogre/.stack/global-project/.stack-work/install/x86_64-osx/lts-5.17/7.10.3/pkgdb
global-pkg-db: /Users/ogre/.stack/programs/x86_64-osx/ghc-7.10.3/lib/ghc-7.10.3/package.conf.d
ghc-package-path: /Users/ogre/.stack/global-project/.stack-work/install/x86_64-osx/lts-5.17/7.10.3/pkgdb:/Users/ogre/.stack/snapshots/x86_64-osx/lts-5.17/7.10.3/pkgdb:/Users/ogre/.stack/programs/x86_64-osx/ghc-7.10.3/lib/ghc-7.10.3/package.conf.d
snapshot-install-root: /Users/ogre/.stack/snapshots/x86_64-osx/lts-5.17/7.10.3
local-install-root: /Users/ogre/.stack/global-project/.stack-work/install/x86_64-osx/lts-5.17/7.10.3
snapshot-doc-root: /Users/ogre/.stack/snapshots/x86_64-osx/lts-5.17/7.10.3/doc
local-doc-root: /Users/ogre/.stack/global-project/.stack-work/install/x86_64-osx/lts-5.17/7.10.3/doc
dist-dir: .stack-work/dist/x86_64-osx/Cabal-1.22.5.0
local-hpc-root: /Users/ogre/.stack/global-project/.stack-work/install/x86_64-osx/lts-5.17/7.10.3/hpc
local-bin-path: /Users/ogre/.local/bin
ghc-paths: /Users/ogre/.stack/programs/x86_64-osx

% stack path --local-bin
Run from outside a project, using implicit global project config
Using resolver: lts-5.17 from implicit global project's config file: /Users/ogre/.stack/global-project/stack.yaml
/Users/ogre/.local/bin

[phadej]

Also, with configure -v

% cabal-1.25 configure -v
Using a sandbox located at /Users/ogre/mess/bytes-0.15.2/.cabal-sandbox
/usr/local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /usr/local/bin
found ghc-pkg in /usr/local/bin/ghc-pkg
/usr/local/bin/ghc-pkg --version
/usr/local/bin/ghc --supported-languages
/usr/local/bin/ghc --info
Reading available packages. <--- from where

[ezyang]

It would be a simple matter to clean up the -v output. @headprogrammingczar would you be interested in writing this patch?

[headprogrammingczar]

I will if nobody beats me to it, after I finagle my bash aliases and directory structure to be friendlier towards rapidly developed git repos.

[ezyang]

Haha, sorry about that! I'm a big fan of git-new-workdir; I use it for all by Cabal build trees.

[headprogrammingczar]

It looks like the information already gets output, in a limited form, buried deep in the "cabal configure -v" output:

Using install prefix: /usr/local
Binaries installed in: /usr/local/bin
...

This information comes from Distribution.Simple.GHC.pkgRoot which depends on LocalBuildInfo, meaning it's impossible to know until late in the configure process. Making what's already there more readable will solve the original issue of giving newbies just one command to run, but is also a much larger task (and even more so if verbose output of the other commands is prettied up too).

Attached is an example of what cleaner verbose output might look like. Comments?
cabal-verbose.txt

[ezyang]

Hmm, I guess we could introduce a new verbosity halfway between default and -v, which outputs just the stuff you wanted here. Critically, I think, is this would not print out what commands Cabal executes (-v prints this and its useful, but the /usr/bin/pkg-config command is pretty long). Then you could just go and find all the sites which output this info, and just lower the needed verbosity level.

I support cleaning up our logging. It starts with specifying how you decide what gets logged when.

[headprogrammingczar]

I was using a machine with an older version of cabal to make that output, if you're just not seeing something you expected. I wouldn't expect any information to get removed in reformatting the log output, unless you think these are worth doing at the same time.

[ezyang]

No, that's basically what I expected ;) My experience with logs has always been, there's always more than what you're interested in, you have to dig to find the relevant information. But if you just want to add a few extra log statements that's OK too.

I'll point out that by the time we do this in Configure:

    let packageDbs :: PackageDBStack
        packageDbs
         = interpretPackageDbFlags
            (fromFlag (configUserInstall cfg))
            (configPackageDBs cfg)

we already know exactly what package databases we're going to use. packageDbs could be immediately printed at this point.

[headprogrammingczar]

I found out the hard way that type is too high-level to get a path from directly. If you print packageDbs you're not going to get "/path/to/globaldb", you're going to get "GlobalDB".

[ezyang]

Oops. getGlobalPackageDB is a per-compiler function that reads out the full value. You'd probably want to refactor the one-off code in cabal-install/Distribution/Client/Exec.hs that invokes this into one to interpret this flag.

[lspitzner]

#2882 included at least some of the requested info. The PR is bitrotten by now though, by all likelyhood.

[jneira]

This talks partially about sandboxes, which are deprecated. And

A common question in #haskell on freenode is where package files are located.

there is no a "common" question anymore at least inmy experience aorung libera haskell chat

We have a incoming cabal status, which could give us other useful paths: #7500, so i would close this with that pr