Easy way to get last change

chipaca 2017-04-11 12:29:22 UTC #1

I think it’s fairly common that, when you want to get a change, it’s the last one you want. Can we either

make “last” the default, i.e. snap tasks -> you get the last change

con of this is that it’s not entirely obvious that you’re getting the last change
make snap tasks --last work

con of this is that the options parser we have doesn’t make it easy to have “this argument is required unless this flag is set” (i.e., more manual option wrangling)
make snap tasks last work

con of this is that if changes ever become alphanumeric, we need extra special wrangling. Also “snap tasks last” sounds like an order, not a request

any others?

niemeyer 2017-04-11 13:46:14 UTC #2

One concern I have with this is that it encourages a use pattern which is naturally flaky. We can’t ever tell what the last one really is, but I suspect that when people type out --last, they’ll be thinking of that one, if you see what I mean, but may be surprised by something else entirely that has shown up since they did the manual action.

One way around that would be to offer a more stable view. For example, we might have a --refresh flag, which shows the last refresh available, and --install, with the respective semantics, etc.

What do you think?

pedronis 2017-04-11 14:04:49 UTC #3

also there’s auto refreshes that could happen any time in between

niemeyer 2017-04-11 14:06:48 UTC #4

As long as we skip the empty ones, that’s perhaps okay. The command might actually be looking for the auto refresh itself.

pstolowski 2017-04-20 16:07:34 UTC #5

I’ll be happy to work on that next, unless this is something you wanted to do @chipaca? The idea to have --refresh and --install flags etc. looks sensible to me. I can start working on this soon once I land some of my current PRs.

chipaca 2017-04-20 16:23:49 UTC #6

snap tasks --last <verb> with verb being refresh, install, etc? Is that doable even?

chipaca 2017-04-20 16:24:24 UTC #7

FTR I’m not too worried about who gets to make things better as long as they get better

niemeyer 2017-04-20 19:46:15 UTC #8

That sounds good, and yeah, it seems easily doable.

pstolowski 2017-04-21 11:56:52 UTC #9

The PR: https://github.com/snapcore/snapd/pull/3217