Snapcraft's state tracking improvements

[Didier Roche]

Le 13/12/2016 à 22:57, Kyle Fazzari a écrit :
> Hey everyone.

Hey Kyle
>
> I feel it coming on... this is going to be a tome. tl;dr... snapcraft
> could be smarter than it is. But would that lead to its doing more for
> you than you want? We'd like to find out.
>
> I've spoken to a few of you individually about this, and I want to open
> this topic up for wider conversation. We have a number of bugs logged
> against snapcraft for its state tracking shortcomings. For example, a
> few of you may have run into these issues:
>
> - You add a stage package to a part in an already-built snap, and run
> `snapcraft` again. It happily says all the steps have already run, and
> generates a snap that doesn't contain your stage package.
>
> - You add (or modify) a file in the local source for a part of an
> already-built snap, and run `snapcraft` again`. It again reports that
> everything has already run, and generates a snap that doesn't contain
> your modifications.

There is another one: there is a remote source which changes. I think
snapcraft can be smarter about that and store the hash of the git/bzr
commit id, and check if new remote hash is the same or not. This is a
little bit more problematic for other kind of assets like tarballs, as
you can only create and check a checksum (if not published) after
downloading… defeating the caching purpose :)

> The point is: snapcraft is/will be smart enough to help a lot more than
> it currently does in these types of situations. The question I'm posing
> to you all is: how much do you want its help?
>
> I see four options for how to handle such situations:
>
>
> *Option 1*: Error out and make you be specific. This is the current
> behavior.
>
> *Option 2*: Automatically take care of everything. If you modify a part
> with dependencies, snapcraft will rebuild those dependencies as it sees
> fit without your needing to say so. Similarly, if you clean a part with
> dependencies, snapcraft will clean those dependencies as it sees fit
> without your needing to say so.
>
> *Option 3*: Prompt. "You've modified part A, but part B depends upon it.
> Would you like to rebuild it as well? (Y/n)" and the like.
>
> *Option 4*: Add the ability to configure this behavior between options
> 1-3. Perhaps the sensible default would be option 3.
>
>
> Our goal here is to do the least surprising thing, which is why we're
> asking for input from our users. Please let your voice be heard!

I would think a good way is always to not try to be too smart. This is
kicking back in some way in the future. I would personally go with
option 1 + a suggestion of command to run to autofix it. Instead of
prompting (option3), add an option like --auto (or --force).

This gives a sane default behavior, and let then integration tools (like
IDE integration or scripts) to use the --auto after detecting a failure.
Then, they can decide themselves to do it right away or to prompt the
user (which is harder if you implement option 3 as a CLI prompt).

Option 4 sounds dangerous to me, because there are mutiple situations
which can triggers this, and so, if you set auto as a default for
everything, you can go trigger surprising behavior for certain cases.
Here is my 2 cents