<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 2:37 PM, Sergio Schvezov <span dir="ltr"><<a href="mailto:sergio.schvezov@canonical.com" target="_blank">sergio.schvezov@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
El 16/03/16 a las 14:04, Gustavo Niemeyer escribió:<br>
<span class="">><br>
> [moving this thread to snappy-devel@ -- this is the best public forum we<br>
> have to discuss these implementation details with relevant parties]<br>
><br>
> Thanks for opening that conversation up, Sergio.<br>
><br>
> It's precisely the right moment for us to figure that one out, because<br>
> we need to talk about how we want the gadget and kernel snaps to really<br>
> look like, and the decision we make for gui may serve as good guidance<br>
> there.<br>
><br>
> Regarding your dislike option 1, I feel like the distinction between<br>
> both approaches in those terms is too small as far as users is<br>
> concerned. Having to know about a specific file name in a specific<br>
> subdirectory is not much harder than having to know about a specific<br>
> yaml key under a specific yaml parent key. In fact, it's simpler IMO,<br>
> because that yaml key would point to a file path. So you need to know<br>
> the file path in addition to the yaml key anyway, and because we<br>
> wouldn't have an enforced convention for the file path, people would put<br>
> those files anywhere they please, making snaps look less alike than they<br>
> could otherwise.<br>
<br>
</span>So my strategy so far was that you specify the artifact and snapcraft<br>
would make sure it goes to the right location. An icon regardless of<br>
where it pointed to would end up in `meta/gui/icon.<png|svg>`.<br></blockquote><div><br></div><div>Right, that fits into what I covered above: the user needs to know about a particular yaml key name and location, entering a local path by hand, which will differ across snaps.</div><div><br></div><div>Having setup/gui/icon.png feels better all around.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Likewise for the config hook, which far from the simple snap examples we<br>
have built config hooks as use cases.<br>
<span class=""><br>
> So my preference is in Option 1. Which moves us to the next question:<br>
> where to store it?<br>
><br>
> My own real preference was ruled out a long time ago. I'd like to have<br>
> named parts/ as snap/parts/, so we'd have the snap/* namespace for that<br>
> sort of thing. But it's far too late to change that like this.<br>
><br>
> It also feels unreasonable to pick up parts/gui/. It's way too close to<br>
> a normal part name, and it also establishes a precedent that we don't<br>
> want to continue using. Otherwise, once we need something else than<br>
> gui/, what do we do?  Pick another name there?  The end result won't be<br>
> pretty.. in the same namespace we'll have a mix up of real part names<br>
> and blacklisted names that are totally unlike parts. Ugh.<br>
<br>
</span>My opinion about using `parts/gui` was just to follow suit with what is<br>
already a reserved path for local project plugins `parts/plugins`<br></blockquote><div><br></div><div>That's slightly less awkward (slightly :), because parts/plugins is indeed about the part plugins. I wouldn't take that as a good model to base other features upon.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> So, here is an idea: in the last sprint we agreed to use the "setup/"<br>
> directory for snapcraft's benefit with the gadget snap.<br>
><br>
> What if we establish that *known* content in setup/<path> ends up in the<br>
> snap's meta/<path>, as a more general convention?<br>
><br>
> This solves the gui case (setup/gui/<app>.desktop), and opens<br>
> appropriate doors for the gadget and kernel snaps.<br>
><br>
> Comments?<br>
<br>
</span>I am ok with `setup/gui` but it also feels like many projects would use<br>
a `setup` directory (I say feels as I lack proper research). If no one<br>
is in nay, I will start a migration path towards this.<br></blockquote><div><br></div><div>I don't recall seeing such a directory, but it's such a good name I wouldn't be surprised something else is picking it up too. It's easy for us to have an alternative path via snapcraft.yaml when this one is taken.</div><div><br></div><div>Let's go ahead then?</div><div><br></div><div><br></div><div>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br></div></div>
</div></div>