"installed" field in snap info *NOT* becoming "current"

snapd
1

This is an advance notice; the change is not due to appear in snapd until 2.33.

We’re doing changes to snap info output to provide more and better information, and as part of the preparatory work we’re renamed the installed field to current.

The rationale is that installed could, at a later release, be a timestamp (rather like refreshed today).

2

Thanks for the warning. Could you confirm that this change will only affect the snap info command itself and does not imply any changes to the fields or information provided by /v2/snaps REST API?

1 Like
3

If it affects the REST API we will need to SRU a new version of snapcraft or everything build-snaps would potentially break. I look forward to keeping backwards compatibility on the REST API until such thing happens.

4

This change does not affect the REST API, no.

There’s another change that affects the REST API, that I didn’t thing worth calling out: install-date (that’s used for refreshed) is currently wrong, and we’re fixing it (hopefully).

1 Like
5

Can we not just add an install-date: field in snap info? I prefer ‘installed: version’ to ‘current: version’ because the concept of ‘current’ is ambiguous. Is it ‘current’ for the publisher, or ‘current’ for the user? Installed, on the other hand, is unambiguously the position of the user.

6

Hmm… that would certainly also work. For consistency we’d need to change refreshed to … last-refresh-date? That might be a bit long, but does fit as long as it’s not trying to line up with anything longer than itself. Just refresh-date might be construed as being a future date, but might work especially if we default it to relative dates for ones that were recent — in fact, maybe we should go that way instead.

last-refresh-date: 2018-02-25T13:41:48Z
install-date:      2017-09-14T13:41:48Z

vs

refresh-date: 3 days ago
install-date: 2017-09-14T13:41:48Z

or maybe

refresh-date: 2018-02-25T13:41:48Z (3d4h ago)
install-date: 2017-09-14T13:41:48Z (160d ago)

hmm. That last one works.

(fwiw, having a correct user-centric install-date isn’t ready yet, but it’s what we’re aiming at)

7

That last option looks quite nice. As one detail, would be better if the deltas had a fixed unit, so that they can be quickly scanned and compared. Something like this:

refresh-date: 2018-02-25T13:41:48Z (3 days ago)
install-date: 2017-09-14T13:41:48Z (160 days ago)

But, maybe this would be better:

refresh-date: 3 days ago at 13:41
install-date: 160 days ago at 13:41

Actually, that looks quite a bit better to the eye. And we can use your suggestion of having a command line flag to request times in RFC3339 form for programmatic usage. We also need to special case “today” and “yesterday” so it doesn’t look awkward.

8

For clarity, the change to the snapd API is that the date is changing to be the expected one. The API won’t break.

9

This isn’t a very human-friendly date:

|2018-02-25T13:41:48Z|
1 Like
10

Yeah, we have ISO 8601 everywhere, in snapd and snapcraft. I’d love to see that be more friendly across the board.

11

Updated the topic title to reflect the new new :slight_smile:

@kyrofa let’s chat about an approach to dates that works for both of us. The current thinking is that we want, for any snap command that produces dates, a flag to switch between “human” and “machine-friendly” dates, the former being relative (either long form or short form depending on context), the latter being RFC3339 (same as ISO 8601 afaik) .

12

@chipaca indeed, let’s! I have some questions though-- perhaps a new topic would be best?

13

Let’s chat on IRC or telegram and then create a topic from there.

14

The changes discussed are up for review:

https://github.com/snapcore/snapd/pull/4796

that’s a first pass, to be tweaked after chatting with @kyrofa.

15

Had a nice chat with @kyrofa. We’ve agreed to take snapcraft and snapd towards the same place wrt displaying dates to the user: by default, we’ll

  • use the last format recommended by Gustavo, for dates that are up to 30 days away.
  • use ISO date format (YYYY-MM-DD) for dates further away than that.

This last change is because after a certain amount of time, it’s hard to know when a number of days was. “177 days ago” vs “2017-09-12”, for example.

Also, we’ll have both projects use the same flag to switch the behaviour to using RFC3339 dates. We’ll be using --absolute-times unless something better is found.

I’ll be pushing these changes to the above PR shortly.

16

Idea looks great as a whole. Some minor suggestions on it:

  • Start with 60 days, as it feels slightly better as a transition from very recently to somewhere in the past. 30 might even fall in the same month, and the absolute format flattens everything out.
  • Use --abs-times as the argument