@psibi this is awesome! I wanted this from day one. See #1614 which links other issues as well asking for the same thing.

@harendra-kumar Thanks. I didn't know the existence of the other issue. I modeled the interface loosely around nvm. Let me know if you feel there should be any specific changes to the interface.

I have the following suggestions:

1. As proposed in A new stack show command and missing informative commands #1614 we should make an umbrella list command for different types of things to list. What you have implemented would fall under stack ls snapshots subcommand. You can just create the snapshots subcommand for now and more commands can be added to it later.

2. The default output snapshots should be the same as or similar to what stack init --solver tries for resolution. It should be concise and useful for common case.

3. make local and remote as flags of the subcommand snapshots. Even for those limit the output to some threshold or use the pager.

4. You can use something like --all to produce full output, though it should not be needed if we are using a pager. I guess there is already a pager implementation in stack code base.

ping @mgsloan

This would be very useful if I could pipe the output through jq, like stack ls remote --format json | jq '.releases[] | sort_by(.date) | select(.name | startswith("lts-")) | .[0]' which would(?) select the latest available lts release.

Note that the above PR will work only when the new stackage server code is deployed.

Seems that change was merged! Nice one.

@psibi, any movement on getting this mergeable? What's left to do?

So finally got some time to work on this!

Some updates:

• Now we have an umbrella ls command as proposed by @harendra-kumar
• I also use the existing Stack's pager implementation for showing the output
• local and remote are sub commands of the snapshot command.

This is the current help message:

~/g/stack (stack-ls) $ stack ls snapshots --help
Usage: stack ls snapshots COMMAND [-l|--lts] [-n|--nightly]
  View local snapshot

Available options:
  -l,--lts                 Only show lts snapshots
  -n,--nightly             Only show nightly snapshots
  -h,--help                Show this help text

Available commands:
  remote                   View remote snapshot
  local                    View local snapshot


~/g/stack (stack-ls) $ stack ls snapshots remote --help
Usage: stack ls snapshots remote
  View remote snapshot

Available options:
  -h,--help                Show this help text

A few thoughts on the UI/UX:

Personally, I'd prefer a more descriptive name than ls which I find very general. Maybe list-snapshots in analogy to list-dependencies?!

Also, how about simplifying the UI a bit by making the remote subcommand a default, and having --local as a flag? Then stack list-snapshots would list all the remote snapshots.

I guess it would be nice to get some integration for custom/extended snapshots but I haven't used them and have no idea how to achieve that.

@sjakobi the ls command is an umbrella command for listing all kinds of things as discussed in #1614. This is not specific to snapshots. What @psibi has done is two separate things in this PR, 1) introduce the ls command group as per #1614, 2) introduce a subcommand ls snapshot to list the snapshots.

In fact the list-dependencies command should now be made a subcommand of ls. The command group ls would reduce clutter at the top level of CLI where we already have a lot of noise.

I like the idea of making remote as default.

@sjakobi the ls command is an umbrella command for listing all kinds of things as discussed in #1614. This is not specific to snapshots. What @psibi has done is two separate things in this PR, 1) introduce the ls command group as per #1614, 2) introduce a subcommand ls snapshot to list the snapshots.

Thanks for clarifying, @harendra-kumar! I should have read the comments here more thoroughly.

LGTM for the most part, just a couple comments. Thanks for working on this, it's good stuff! Sorry for letting it languish so long!

In the future it'd be cool to open an issue first so design can be discussed, but no biggie. This way we can hopefully end up with an initial implementation that's closer to what will be merged.

@mgsloan Left some comments on your review.

In the future it'd be cool to open an issue first so design can be discussed, but no biggie.

Yeah, I totally agree. And I guess that's the reason it has been pending for quite some time.

And I guess that's the reason it has been pending for quite some time.

Yes, part of it! My initial reaction was "Why does 'stack ls' have such a generic name?" - I should have been more open to a feature PR, but also would be good to discuss first. It became more likely to procrastinate doing review once it was already late. Going to try to avoid that cycle in the future!

I've switched to firefox so hopefully the "my browser window with all the stack issue tabs didn't get ressurrected" problem won't happen anymore.

Actually, I'm not sure if the discuss first approach is always needed, or even whether it is a good thing to require / recommend. After all, necessity is the mother of invention, so if you solve a problem for yourself by adding a feature, it is probably better to do that than to delay on discussion. Hmm, tradeoffs! Maybe a dual approach. Open an issue like "I am working on thing X, it is going to look like this:" and then keep working on it while discussion happens.

Some updates about the previous commit:

The ls subcommand interface is similar to previous one but we have done
some minor changes:

If a user gives just stack ls snapshots, then by default we show the
local snapshots available.

Also based on @mgsloan's input, I don't always use a pager now. Also a
new convenience API has been added to PagerEditor.hs which exports a
function pageText. We use that in our module to pass Text content
to pager. (We were using ByteString previously).

The latest commits addresses all the comments above. So, there is no pending
issues remaining in the PR. (I will fix hlint related style issues if something arises)

LGTM, yep just some hlint errors to resolve

Good work! Just the one tweak to the changelog and this can be merged.

I like the style of having additive commits while working on a PR, makes reviewing easier. However, once ready for merge, it can be nice to squash it down to a single commit. Not a big deal, I'd merge it either way.

The build failure is happening in Travis because of timeout issue and is not related to the code. I think somebody from the Stack team has to restart the particular failing build.

However, once ready for merge, it can be nice to squash it down to a single commit.

The main idea here is to not pollute the history with commits that do not add a logically significant change but are just cleanup or random change kind of stuff. So I guess it should be ok to squash it into multiple commits as long as you know that those are logically independent significant steps.

Also, we have added an umbrella ls command here so we should also have a plan (raise an issue?) to move other commands e.g. list-dependencies under it and make sure (keep a watch) that in future other such commands are added under it and not outside.

Nice work @psibi!

@harendra-kumar The github interface allows the committers to squash and merge the commit of this PR. So, I'm leaving the option to the committers. :-) I can squash and merge myself, if others also feel so.

I plan to raise other issues soon.

Nice one @psibi! Should we open a ticket for adding documentation too?

Thanks for your hard work @psibi ! Other tickets and PRs certainly encouraged.