"ls dependencies" should have an option to maintain the tree structure #4101
Comments
|
Hello @sschuberth . That sounds like a helpful enhancement. How much of what you would like to do can you achieve with |
|
I was thinking about (mis-)using |
|
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? |
|
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. |
|
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. |
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.
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. |
|
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,
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. |
|
@borsboom — it may be worth supporting this enhancement to support the OSS review toolkit project mentioned earlier. |
|
I'm very much in favour. I've often wished for an |
I think |
|
And so do Maven ( |
|
NPM does as well: @sschuberth I'm sure you've seen @borsboom Why does |
|
The problem with NPM is that it can only show the tree for installed dependencies. But ideally I'd like to see the list / tree of dependencies before I even install them. Maven and Gradle can do that just fine. Thanks @creichert, I've seen |
|
I was exploring the |
Add option to print dependencies as tree First part of #4101
|
@akshaymankar For machine readable output I suggest json (unless @sschuberth has a better suggestion). It might be simple enough to implement some aeson instances and then plumb them in. SPDX is well defined. For the URI, I'm not sure what to go with. I don't really understand the use case, so perhaps @sschuberth can explain. |
|
JSON is indeed fine from my perspective. But if e.g. more common in the Haskell community, YAML could be another option. URI / URL was referring to the direct download location for the source code to the package. At the example of the |
This ensures interface of ls dependencies remains clean and users can only pass options when they make sense [commercialhaskell#4101]
|
The URL in the JSON doesn't really work, because a package could either be from hackage, a local package, an archive specified by URL or a git repository. So, I guess a URL to a will not always be possible. I am not sure what the best possible format for this would be. @sschuberth, do you have any suggestions/preferences? @dbaynard I also couldn't find a place where stack figures out URL from |
|
@akshaymankar what's the problem to use |
|
And I think you'll need a custom function for that, I don't think there's already some code doing that. |
|
I was also about to say a URL should work:
|
I think @qrilka was answering the question you asked of me. |
|
I think Maybe it could look something like this for git (and similar for hg): {
"name": "foo",
"version": "1.0.0.0",
"license": "MIT",
"location": {
"type": "git",
"url": "<URL provided by user>",
"commit": "<sha>"
}
}For hackage: {
"name": "foo",
"version": "1.0.0.0",
"license": "MIT",
"location": {
"type": "hackage",
"url": "<computed hackage URL>"
}
} |
With the changes to the dot command, the test currently fails due to not having the dependencies of the transformers package in the expected output. this fixes the situation.
…4101 Fix integration test for #4101
This ensures interface of ls dependencies remains clean and users can only pass options when they make sense [commercialhaskell#4101]
This ensures interface of ls dependencies remains clean and users can only pass options when they make sense [commercialhaskell#4101]
And thus remove dependency on `aeson-pretty` [commercialhaskell#4101]
This ensures interface of ls dependencies remains clean and users can only pass options when they make sense [commercialhaskell#4101]
And thus remove dependency on `aeson-pretty` [commercialhaskell#4101]
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:treeoutput, but ideally there would also be an option to output to a machine readable format like JSON.The text was updated successfully, but these errors were encountered: