I’m writting a snap and it uses an ‘after: [xxxx]’ clause.
I’m trying to understand if there is something special about the snap(?) mentioned in the ‘after’ clause.
Is it just another snap or is there something different about it that allows it to be used in an ‘after’ clause?
The after keyword is not meant for another snap.
It’s used in the building process of your snap, and used so a part can be built after one of your other parts.
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:.
Do the question is, how do I write a remote part, or at least a reusable part.
Right now that wiki page is how you define the remote part. Just edit it and include your remote part.
In the near future there will be a more polished service for handling those.
I had seen the wiki page (not certain how that is going to be maintainable long term…) but the question was what does the snapcraft.yaml look like for a remote part.
The doco takes about using a remote part but I don’t see where it says how to build a remote part.
It looks just like any other snapcraft.yaml.
So as an example I added a remote part to the wiki today.
---
origin: https://github.com/popey/nwjs-support.git
maintainer: Alan Pope <alan.pope@canonical.com>
description:
nwjs-support is a part which pulls in the necessary pieces to
support an nwjs application as snaps
parts: [nwjs-support]
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.
Maybe I’ve missed it, but it would be useful to have a few words in the doco on how to make a remote part.
Its obvious once you know how to do it, but that doesn’t help newbies 
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…
I can’t say I agree with your philosophy, sounds rather like ‘security by obscurity’.
I think you are perhaps expecting a little too much if you expect people to maintain parts indefinitely.
To some extent, the more parts the merrier, because they create a base of sample code, which is somewhat lacking currently. The also provide a body of work to build on.
Perhaps a ‘user review’ system that allows users to grade parts as well as seeing how many other people have used the parts. This would seem like a much more useful mechanism.
And to be honest I don’t like any excuse that ends up with poor documentation