On Wed, Mar 16, 2016 at 2:37 PM, Sergio Schvezov < sergio.schve...@canonical.com> wrote:
> > El 16/03/16 a las 14:04, Gustavo Niemeyer escribió: > > > > [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 strategy so far was that you specify the artifact and snapcraft > would make sure it goes to the right location. An icon regardless of > where it pointed to would end up in `meta/gui/icon.<png|svg>`. > 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. Having setup/gui/icon.png feels better all around. Likewise for the config hook, which far from the simple snap examples we > have built config hooks as use cases. > > > 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. > > My opinion about using `parts/gui` was just to follow suit with what is > already a reserved path for local project plugins `parts/plugins` > 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. > 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? > > I am ok with `setup/gui` but it also feels like many projects would use > a `setup` directory (I say feels as I lack proper research). If no one > is in nay, I will start a migration path towards this. > 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. Let's go ahead then? gustavo @ http://niemeyer.net
-- snappy-devel mailing list snappy-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
