<div dir="ltr">Thanks kyle, this is really important! In a hackathon event, when the network was bad and shared by many people, keeping cleaning the project and rebuilding the project took a lot of time to build the whole project. Sometime, it took a few tens minutes to get it done!<div><br></div><div>Best regards,</div><div>XiaoGuo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 5:57 AM, Kyle Fazzari <span dir="ltr"><<a href="mailto:kyle.fazzari@canonical.com" target="_blank">kyle.fazzari@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey everyone.<br>
<br>
I feel it coming on... this is going to be a tome. tl;dr... snapcraft<br>
could be smarter than it is. But would that lead to its doing more for<br>
you than you want? We'd like to find out.<br>
<br>
I've spoken to a few of you individually about this, and I want to open<br>
this topic up for wider conversation. We have a number of bugs logged<br>
against snapcraft for its state tracking shortcomings. For example, a<br>
few of you may have run into these issues:<br>
<br>
- You add a stage package to a part in an already-built snap, and run<br>
`snapcraft` again. It happily says all the steps have already run, and<br>
generates a snap that doesn't contain your stage package.<br>
<br>
- You add (or modify) a file in the local source for a part of an<br>
already-built snap, and run `snapcraft` again`. It again reports that<br>
everything has already run, and generates a snap that doesn't contain<br>
your modifications.<br>
<br>
We used to have even more of these issues, but snapcraft has slowly been<br>
getting smarter about things like this. You may have noticed that v2.23<br>
fixed that first problem, for example. Well, sort of. Let me explain.<br>
<br>
Snapcraft's state tracking allows us to do some handy things. For<br>
example, as you probably know, when you run the `stage` or `prime`<br>
steps, you're combining files from multiple parts into a single<br>
directory. Thanks to state tracking, snapcraft is able to disentangle<br>
which files came from which part, and allow you to remove a single<br>
part's files using per-step cleaning.<br>
<br>
However, this is complicated by the ability to have inter-part<br>
dependencies (using the `after` keyword). If part A depends on part B<br>
and part B is being cleaned, then snapcraft knows part A needs to be<br>
cleaned as well. But should it go ahead and clean it for you? What if<br>
you were offline and part A required the internet to build? Or<br>
re-building part A took forever and you didn't want to just wipe it? We<br>
weren't sure when we implemented this ability, so we decided to be safe<br>
and force you to say exactly what you wanted. For example, if you simply<br>
said `snapcraft clean part B` we error out, saying something like "Hey<br>
you're trying to clean part B, but part A depends on it. If you intend<br>
for both to be cleaned, please say so."<br>
<br>
This same mindset can be found elsewhere:<br>
<br>
- If you change something in the YAML that makes a part out of date<br>
(e.g. stage packages) it tells you it's out of date and why, but doesn't<br>
clean/rebuild it for you.<br>
<br>
- Trying to build part A which depends on part B before B itself has<br>
been staged leads to "Hey, part A has unsatisfied dependencies." If you<br>
run `snapcraft stage A B` it'll do the right thing.<br>
<br>
- Not-yet-released features will know when local sources for a part have<br>
changed, and build the updates, but what should it do if that part has<br>
another depending upon it?<br>
<br>
The point is: snapcraft is/will be smart enough to help a lot more than<br>
it currently does in these types of situations. The question I'm posing<br>
to you all is: how much do you want its help?<br>
<br>
I see four options for how to handle such situations:<br>
<br>
<br>
*Option 1*: Error out and make you be specific. This is the current<br>
behavior.<br>
<br>
*Option 2*: Automatically take care of everything. If you modify a part<br>
with dependencies, snapcraft will rebuild those dependencies as it sees<br>
fit without your needing to say so. Similarly, if you clean a part with<br>
dependencies, snapcraft will clean those dependencies as it sees fit<br>
without your needing to say so.<br>
<br>
*Option 3*: Prompt. "You've modified part A, but part B depends upon it.<br>
Would you like to rebuild it as well? (Y/n)" and the like.<br>
<br>
*Option 4*: Add the ability to configure this behavior between options<br>
1-3. Perhaps the sensible default would be option 3.<br>
<br>
<br>
Our goal here is to do the least surprising thing, which is why we're<br>
asking for input from our users. Please let your voice be heard!<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Kyle Fazzari (kyrofa)<br>
Software Engineer<br>
Canonical Ltd.<br>
<a href="mailto:kyle@canonical.com">kyle@canonical.com</a><br>
<br>
</font></span><br>--<br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.snapcraft.io">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/snapcraft</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">XiaoGuo, Liu </div></div></div></div>
</div>