Code review comment for lp://qastaging/~ted/snapcraft/ros-catkin-plugin

On Fri, 2015-10-02 at 22:39 +0000, Sergio Schvezov wrote:

> I've been giving this a bit more of a look and I don't think we want
> config={} at all, parts should not have knowledge of config, it is
> what keeps them independent. We also don't want to have it write a
> services entry, that should be in the users control.

So, I actually think the opposite, we need it more or an actual step for
it.

I think that we do want the plugins to provide smarter generation of the
packages.yaml file, we can argue whether they should do services, but I
think we definitely want them to do frameworks and add capabilities on
individual binaries/services/etc. The case I'd mention is the QML
plugin. For QML to be useful it needs the Mir Framework and every binary
needs to have the mir_client capability. I don't think that we should
require the developer to understand those, just understand that he/she
needs to pull in QML. The QML plugin should add those onto the packages
file where it can.

Perhaps a solution for the services would be to provide a way to insert
a commented block into the packages.yaml file. So the plugin could see
if there was a ROS Master and if not throw some comments in saying "hey,
you might want these keys."

While for ROS I think this isn't as important, but as we start adding
things to the wiki you'd want to add postgres to your snap, not
configure postgres as a server in your snap. It seems that there needs
to be some way to have the service come along with the plugin.