"ls dependencies" should have an option to maintain the tree structure

[sschuberth]

Currently, "ls dependencies" just outputs a flat list of package names and versions of all transitive dependencies of a project. However, it would be nice to maintain the tree hierarchy of dependencies to see their parent / child relationship. On the console, the tree output could look similar to Maven's mvn dependency:tree output, but ideally there would also be an option to output to a machine readable format like JSON.

[dbaynard]

Hello @sschuberth . That sounds like a helpful enhancement. How much of what you would like to do can you achieve with stack dot --external (perhaps with --include-base, too)?

[sschuberth]

I was thinking about (mis-)using stack dot, too, but while it basically provides the parent -> child relationship, it's a bit inconvenient to parse, also because it repeats the parent for each child. The versions are missing, too, but together with the output from stack ls dependencies I could probably get what I want. I'll give it a try.

[dbaynard]

That's all useful to know. It may be relatively straightforward to reuse the code required for the dot output. Would you be willing to contribute a PR yourself?

[sschuberth]

I'm sorry, I'm not a Haskell guy (and I don't intend to become one 😉), I'm just trying to add basic Haskell support to the OSS Review Toolkit.

[dbaynard]

Oh, that's an interesting project. Is there anything else that would be helpful for you to achieve that, from stack?

It might also be possible for you to do what you intend using the hackage or stackage APIs directly (depending on scale), though they are quite limited. If stack meets your other requirements, then great.

[sschuberth]

Is there anything else that would be helpful for you to achieve that, from stack?

Thanks for asking. Besides listing dependencies as a tree (optionally in a machine readable format), it would be nice if the shown meta-data would not only include the name and version, but also the dependency's declared license (as an SPDX identifier). That would be the very minimum, IMO. More meta-data like the download URL would also be interesting and could be added, or simply a link to the respective hackage or stackage (REST?) APIs endpoints where more information can be gathered by the client (the program using the meta-data output) on demand.

In general, from a performance perspective it would be nice if all this meta-data could be gathered without internally downloading and unpacking the whole (source code of a) package, i.e. ideally meta-data for a package and the package itself should be separated, similar to Maven POM and JAR files.

using the hackage or stackage APIs directly

While I've found http://hackage.haskell.org/api, I didn't find something similar for stackage. Is there? Edit: I just found https://groups.google.com/forum/#!topic/stackage/9h_RA-jNz_g.

[dbaynard]

Perhaps we should broaden the issue, then. It seems like a useful addition, though it may not be a priority for the core team.

So to summarize,

• List dependencies as tree

• List dependencies in machine readable format

• List license as SPDX in addition to name and version

  Most cabal files don't use these identifiers; internally Cabal (which processes these files and is different to cabal-install, the provider of the command line program cabal) uses an enumeration, though, so you may wish to take a look thee.

• List URI too

In general, from a performance perspective it would be nice if all this meta-data could be gathered without internally downloading and unpacking the whole (source code of a) package, i.e. ideally meta-data for a package and the package itself should be separated, similar to Maven POM and JAR files.

stack downloads and unpacks the hackage tarball (~100MB compressed), which contains the cabal files where the metadata is located; this might update incrementally (I've never investigated). The cabal files themselves are reachable directly (/package/:package/:cabal.cabal). So the trade-off is a space vs latency one. If you're happy with the space use, stack would be useful for this.

I didn't find something similar for stackage

I think I might have just tried the hackage endpoints when I was looking for snapshot information… or I may have checked the api calls in the debugger. I think the hackage api is most relevant, though — I only needed stackage because of stack snapshots. That said, it may be useful to add the hackage mirrors, if you go that way.

[dbaynard]

@borsboom — it may be worth supporting this enhancement to support the OSS review toolkit project mentioned earlier.

[borsboom]

I'm very much in favour. I've often wished for an ls-dependencies that shows the tree structure. That said, I'm going to un-assign myself as it's very unlikely I'll actually be able to work on implementing it.