List packages via `snapd` REST API

[stevenwilkin]

This is a first step in migrating WebDM to the snapd API and simply processes the response from the /1.0/packages endpoint.

Maybe a bit heavy handed when it comes to tests but there's a lot of error conditions...

[snappy-m-o]

Can one of the admins verify this patch?

[chipaca]

ok to test

[mvo5]

Thanks for this pull request. The branch looks very nice. Tests looks reasonable, no worries there :) 👍 from me.

One question about how this is going to be used inside webdm. I was assuming webdm would call snappyd directly via JS, is the plan to do something different? Don't get me wrong, the branch is fine and we need it in our work to move our cli client to the REST API, I just wonder how it relates to webdm.

[stevenwilkin]

Cheers for the feedback @mvo5!

The situation is thus: to move away from calling the snappy code directly the existing Go API in WebDM (confusingly called snappyd, maybe it should be renamed?) will have to handle all communication over the socket to snapd and transform the data into something the JS app can consume. The operations it will perform are:

• list all packages
• retrieve details for an individual package
• install a package
• remove a package

So a bunch of Go needs to be written by myself to handle interactions with these specific endpoints in the API. I could keep it all in WebDM but if there are other projects which will need to do the same then it seems sensible to have a single source of truth which a greater number of people can contribute to and fix bugs in.

As has been mentioned in IRC by @chipaca, the ideal situation would be to split out the client into it's own project but that's a bigger concern involving the snappy command etc from what I can tell.

Perhaps a snappy-client/rest lib or similar could be a suitable compromise until such time as efforts could be focused to fully separate the client and daemon code...

If you think I'm barking up the wrong tree then don't feel shy to say so 😎

[chipaca]

👍