Snapcraft's state tracking improvements

[Stuart Bishop]

On 14 December 2016 at 04:57, Kyle Fazzari <kyle.fazzari at canonical.com>
wrote:

> Hey everyone.
>
> 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.
>


>
> *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.
>

I would prefer a reliable Option 2. If it can't be reliable, then Option 1.



*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.
>

No thanks. There seems little purpose to answering 'no', apart from blowing
off your foot. And useless if you are driving this from a Makefile or
similar (think generating your snapcraft.yaml).


> *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 found it annoying that I would need to run three or more commands to
build my snap when iterating, and would certainly like it if cleaning and
rebuilding happened automatically if I have touched relevant source code.
People might need to separate out their parts into different directories to
make this reliable. A problematic case I would have tripped over is a slow
building autotools project, in which I've added a snapcraft.yaml and some
Python wrappers. I would not want to trigger a rebuild of the autotools
part because I'm fixing a bug in my wrappers (a second part, but stored in
the same tree). Maybe you could handle this by monitoring the files opened
by the build process somehow?


-- 
Stuart Bishop <stuart.bishop at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161215/8cccdc27/attachment.html>