<div dir="ltr"><div><br></div><div>[moving this thread to snappy-devel@ -- this is the best public forum we have to discuss these implementation details with relevant parties]<br></div><div><br></div><div>Thanks for opening that conversation up, Sergio.</div><div><br></div><div>It's precisely the right moment for us to figure that one out, because we need to talk about how we want the gadget and kernel snaps to really look like, and the decision we make for gui may serve as good guidance there.</div><div><br></div><div>Regarding your dislike option 1, I feel like the distinction between both approaches in those terms is too small as far as users is concerned. Having to know about a specific file name in a specific subdirectory is not much harder than having to know about a specific yaml key under a specific yaml parent key. In fact, it's simpler IMO, because that yaml key would point to a file path. So you need to know the file path in addition to the yaml key anyway, and because we wouldn't have an enforced convention for the file path, people would put those files anywhere they please, making snaps look less alike than they could otherwise.</div><div><br></div><div>So my preference is in Option 1. Which moves us to the next question: where to store it?</div><div><br></div><div>My own real preference was ruled out a long time ago. I'd like to have named parts/ as snap/parts/, so we'd have the snap/* namespace for that sort of thing. But it's far too late to change that like this.</div><div><br></div><div>It also feels unreasonable to pick up parts/gui/. It's way too close to a normal part name, and it also establishes a precedent that we don't want to continue using. Otherwise, once we need something else than gui/, what do we do?  Pick another name there?  The end result won't be pretty.. in the same namespace we'll have a mix up of real part names and blacklisted names that are totally unlike parts. Ugh.</div><div><br></div><div>So, here is an idea: in the last sprint we agreed to use the "setup/" directory for snapcraft's benefit with the gadget snap.</div><div><br></div><div>What if we establish that *known* content in setup/<path> ends up in the snap's meta/<path>, as a more general convention?</div><div><br></div><div>This solves the gui case (setup/gui/<app>.desktop), and opens appropriate doors for the gadget and kernel snaps.</div><div><br></div><div>Comments?</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 12:53 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello all,<br>
<br>
Do we have snappy documentation about `meta/gui`?<br>
For the snapcraft side of things I've been thinking about two options,<br>
both have pro and cons.<br>
<br>
# Option 1<br>
<br>
I was thinking of moving everything to be by convention by reserving the<br>
`part` name of `gui` so we can have `parts/gui`<br>
<br>
This is not my favorite option as it is hard to hand hold users, it is<br>
also the thing I really disliked about debian packaging (contrary to<br>
spec files) when I started out; there is a file for everything that you<br>
just need to know about.<br>
<br>
<br>
# Option 2<br>
<br>
Expand snapcraft.yaml to take into account the gui bits in a top level<br>
`gui` entry similar to `apps`.<br>
I'm not suggesting putting this under `apps` directly as I guess there<br>
is a reason it wasn't done in snap.yaml either.<br>
<br>
The con here is our snapcraft.yaml will get really blown out in favor of<br>
one view of everything and a unique schema check.<br>
<br>
<br>
Opinons? I don't like either option myself (I also lack context of<br>
`meta/gui`s full role), so reaching out internally to get some feedback.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>

</div></div>