search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
4k stars 843 forks source link

Feature Request: Expose sha256 in ls dependencies json #5274

Open aherrmann opened 4 years ago

aherrmann commented 4 years ago

Feature Request

I would like the output of stack ls dependencies json to contain sha256 and size of packages. AFAIK this information is already available in the snapshots, but currently not exposed through stack's CLI.

Motivation

The upcoming release of stack contains the new stack ls dependencies json feature which returns the package dependency graph and some additional package metadata for a given project (package names, versions, locations, dependencies) in a JSON format. This is very useful for build tools that would like to call out to stack to determine how to fetch sources of Stackage dependencies. The motivating use-case is Bazel with rules_haskell, see https://github.com/tweag/rules_haskell/issues/1310. Though this may also be beneficial for other build tools.

sschuberth commented 2 years ago

Looks like https://github.com/commercialhaskell/stack/releases/tag/v2.5.1 added this, or?

aherrmann commented 2 years ago

@sschuberth Thanks for the ping. The feature is included for archive dependencies.

From #5280

Note, this does not change the output in case of Hackage or repository dependencies. To my understanding, the PackageLocationImmutable data type does not provide this information for Hackage or repository dependencies. Instead, it provides the BlobKey/TreeKey size and hashes which are specific to pantry and not directly applicable to check the hash of a fetched tarball, as explained here.

Please let me know if there is a good way to obtain regular sha256/size values for these dependencies within stack, then I'd be happy to extend this change accordingly. Alternatively, users could use all-cabal-hashes for Hackage dependencies.

In rules_haskell we're currently using the all-cabal-hashes workaround. However, it incurs additional complexity and download time. So, if stack could emit this information in ls dependencies json, then that would be preferable.