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 -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft