meta/gui

[Gustavo Niemeyer]

[moving this thread to snappy-devel@ -- this is the best public forum we
have to discuss these implementation details with relevant parties]

Thanks for opening that conversation up, Sergio.

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.

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.

So my preference is in Option 1. Which moves us to the next question: where
to store it?

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.

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.

So, here is an idea: in the last sprint we agreed to use the "setup/"
directory for snapcraft's benefit with the gadget snap.

What if we establish that *known* content in setup/<path> ends up in the
snap's meta/<path>, as a more general convention?

This solves the gui case (setup/gui/<app>.desktop), and opens appropriate
doors for the gadget and kernel snaps.

Comments?


On Wed, Mar 16, 2016 at 12:53 PM, Sergio Schvezov <
sergio.schvezov at canonical.com> wrote:

> Hello all,
>
> Do we have snappy documentation about `meta/gui`?
> For the snapcraft side of things I've been thinking about two options,
> both have pro and cons.
>
> # Option 1
>
> I was thinking of moving everything to be by convention by reserving the
> `part` name of `gui` so we can have `parts/gui`
>
> This is not my favorite option as it is hard to hand hold users, it is
> also the thing I really disliked about debian packaging (contrary to
> spec files) when I started out; there is a file for everything that you
> just need to know about.
>
>
> # Option 2
>
> Expand snapcraft.yaml to take into account the gui bits in a top level
> `gui` entry similar to `apps`.
> I'm not suggesting putting this under `apps` directly as I guess there
> is a reason it wasn't done in snap.yaml either.
>
> The con here is our snapcraft.yaml will get really blown out in favor of
> one view of everything and a unique schema check.
>
>
> Opinons? I don't like either option myself (I also lack context of
> `meta/gui`s full role), so reaching out internally to get some feedback.
>



-- 
gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160316/e7582dce/attachment.html>