A new stack show command and missing informative commands

[harendra-kumar]

There are multiple informative commands available and there are many of them which are missing too. Some available commands are:

• templates
• path
• dot
• list-dependencies
• query

Some missing ones are:

• list available indices (Hackage/Stackage)
• list packages in an index
• list available snapshots/resolvers for an index (stackage)
• list packages in a snapshot

We can have a stack show command and incorporate all of the above under subcommands of show. That will also reduce the top level commands and make the commands better navigable.

We can split off implementation of the missing ones listed above in a separate issue. Those will be really useful to have.

Also see a related issue #1333 .

[mgsloan]

I'd also like to see the ability to list all project targets, and all package flags.

I agree that it'd be great to have a stack show prefix. I'd be in favor of moving templates, list-dependencies (as just stack show dependencies), and query all under a show command. I think this makes a lot more sense than cluttering up the top level interface with informational commands. stack path should stay, because it's used in lots of scripts, lets not break it.

@borsboom Do you think it's reasonable to make a breaking change for this, or perhaps there should be a deprecation cycle?

[borsboom]

I like the stack show idea. A deprecation cycle would probably be good, in case there are any scripts using these commands. Another option would be to have separate list and show subcommands to list multiple things vs. show details about a single thing. Kubernetes' kubectl works this way (well, it uses the harder-to-type describe instead of show) and I find it nice to use.

[harendra-kumar]

I like that distinction (list and show) especially since the definition looks pretty clear and not confusing the user about which one to use.

So the commands that I listed above fall under the list command, all of them. What among the existing commands can potentially be put under show?

[rrnewton]

+1. We are currently jumping through hoops to get the contents of current LTS releases programatically. Specifically, we download the cabal.config directly that we expect to exist at a particular URL such as "https://www.stackage.org/lts-5.13/cabal.config". This is fragile but I don't know of a better way currently.

[sjakobi]

A relevant idea by @spl from #1855:

It would be useful to see a complete list of the available resolvers.

The documentation uses “e.g.” and “looks like” to provide possible patterns of resolver names, but it doesn't give any indication of the bounds of those patterns, instead relying on reader knowledge to fill in the details or on guesses to see if a certain pattern works.

Ideally, I would like to be able to go to an explicit list of resolvers and see what I can use. Also, ideally, this list would have some documentation about each that explains it and how it is different from other (related) resolvers. A more minimal, but still useful, solution would be to add more description on the resolver patterns, or to add links to more details, to the aforementioned documentation.

[mgsloan]

That would indeed be cool. It'd be nice if it told you the usable ranges of lts + what the most recent nightly is.

[psibi]

@harendra-kumar

list available indices (Hackage/Stackage)
list packages in an index
list available snapshots/resolvers for an index (stackage)
list packages in a snapshot

What do you mean by index here ? Do you mean a particular snapshot/resolver (If yes, then the sentence list available snapshots/resolvers for an index ambigous). I'm implementing a way to see the list of packages in a particular resolver and this issue seemed related to it.

[harendra-kumar]

By index I mean either hackage or stackage. It can also be a custom local index which you are maintaining yourself. The resolver/snapshot concept applies to stackage index only that's why I wrote stackage in parenthesis for that item.

[mpilgrem]

I am closing this issue because (a) the lack of activity for a long time (b) the likelihood of subsequent developments and (c) I think it would be better to have separate issues for specific information requirements.