Note, however, that there is a concept of “remote parts” which are defined centrally such as the desktop-* parts which you can use to get the desktop-launch wrapper supporting your GUI toolkit. The currently available remote parts are listed at https://wiki.ubuntu.com/snapcraft/parts. These remote parts do not need to be defined in your own snapcraft.yaml, but can still be used in after:.
So as an example I added a remote part to the wiki today.
maintainer: Alan Pope <firstname.lastname@example.org>
nwjs-support is a part which pulls in the necessary pieces to
support an nwjs application as snaps
If you follow the origin link to github you’ll see the project contains a simple snapcraft.yaml. If I build a project which specifies after: [nwjs-support] then snapcraft will pull that project and incorporate the parts within into my project.
So is there anyway the parent snap can control the features/settings of the child snap.
e.g. I’ve seen a part that contains apache/mysql/php…
I want to use the apache part but don’t want the other components installed.
The same might go for a mysql part. For instance is there some way of telling the part to create a db of a certain name.
I understand the part would need to be constructed to specifically support these type of actions, so my question goes to what are the mechanisms you can use to implement parts that would allow control over these type of actions.
Making it very easy, while good for developers, means that we could get a flood of unmaintained/abandoned remote parts, or potentially useless remote parts. When you add a remote part you’re forming a contract that you won’t break your part’s users’ builds, and will maintain the part indefinitely. Potential remote part writers need to understand that aspect before they commit. This obviously needs to be documented better in general, but that detail needs to be included too…