Remote parts added to new doc site

[bsutton]

@popey I hope you don’t mind but I’ve added you doco on remote parts to the new doco site here:

Remote (reusable) parts

Developers using snapcraft to build snaps can leverage pre-existing ‘remote parts’ in their snap, to save time re-implementing existing components. Developers who have created local parts which may be of use to others, can submit them to the remote part cache for other snapcrafter’s to use. Using remote parts Search for parts The Snapcraft command line tool can search the remote parts cache using the search command. Before issuing search use the update to update the parts list from the remote…

I’ve made a few edits and have a few questions:

@niemeyer I don’t know if you want to check the formatting I’ve applied to this page.

The remote part page discuss copy/pasting a remote part, if the remote part has scripts (e.g. local files) the I suspect the copy paste mechanism doesn’t work. I assume in this case you would need to copy/paste all of the ‘files’ that are part of the remote part.

Can a remote part expose apps? If so how does the consuming snap subsequently expose those parts?

Can a remote part define hooks?

If so how are they merged with the consuming parts hooks. This then leads to the question about setting/getting key/value pairs which rely on the part having a configure hook.

If a remote part can’t have hooks then how can the consuming snap configure the remote part?

Can a remote part expose more than one part: e.g. parts [tomcat-with-ssl, getcert].

Does the remote-part have to expose all parts (errors from the remote-part status server suggests yes). I don’t really want to expose all parts as some of them are just to pull in dependencies and serve no other purpose.

It also feels like there is no easy way to test a ‘remote part’ locally before publishing it. It also feels like we lack a mechanism by which an organisation could build a suite of re-usable parts. This would also answer the above questions on how we test a remote part. The copy/paste mechanism isn’t appropriate as you can’t then maintain the re-usable part in a single place.

If I’ve understood the current situation, I think we should be supporting the more general concept of a ‘re-usable part’ which can either be local or remote. We would need a mechanism to tell snapcraft where to find the library of local parts or perhaps a mechanism to add the parts to a local cache.

This then supports ‘private parts’ repositories as well as providing an effective mechanism to test a part before releasing it.

If re-usable parts are going to be released then it really feels like we should be extending the channel/track concept to remote parts. Remote parts are no different to snaps in that they need to go through a alpha/beta/release cycle. It looks to me that a remote part is either released or not released.

So there’s my two cents worth. Brett

[niemeyer]

Thanks for the document.

The remote part is just the snippet itself, as it would exist in a local snapcraft.yaml file under the parts section. The files come from the source field that is referenced by the part, which will be in the same in both if its was just copy & pasted, which means it should still work.

Parts, remote or otherwise, can’t define apps or anything other than what is possible in a local part. It’s the final snapcraft.yaml that defines those details.

[bsutton]

@niemeyer

The files come from the source field that is referenced by the part, which will be in the same in both if its was just copy & pasted, which means it should still work.

That’s no quite my understanding of a part.

I have parts that use the ‘organize’ keyword to ‘move’ files into place from subdirectories of the snap directory.

e.g.

parts:
  getcert:
      plugin: dump
      source: snap/getcert
      organize: 
         renewal : letsencrypt/renewal-hooks/deploy

Are you suggesting that I shouldn’t have files on the host for a part but rather that each part needs its on git repo?

[niemeyer]

The organize keyword says what to do when copying files out of the part’s own files after the install step is done, into the stage area of the snap (the stage area is just a directory used to aggregate content before it’s final). The default behavior is a straight copy over. That’s true no matter if the content is pulled from a local directory or from a source code repository elsewhere.

For a part to be made public, the part source needs to be public too.

[sergiusens]

@bsutton

It also feels like there is no easy way to test a ‘remote part’ locally before publishing it.

It also feels like we lack a mechanism by which an organisation could build a suite of re-usable parts. This would also answer the above questions on how we test a remote part.

The copy/paste mechanism isn’t appropriate as you can’t then maintain the re-usable part in a single place.

We have a way to accomplish this (mostly for testing reasons), we can make it more user oriented, discoverable and documented.

[sergiusens]

@bsutton

Can a remote part define hooks?

There are two ways to setup hooks,

• An executable file in <rootdir>/snap/hooks/<hook-name>
• An executable file installed by a part to `/snap/hooks/.

While the former, given its nature cannot be shared through a part, the latter should just work.

[sergiusens]

@bsutton

If I’ve understood the current situation, I think we should be supporting the more general concept of a ‘re-usable part’ which can either be local or remote.

We would need a mechanism to tell snapcraft where to find the library of local parts or perhaps a mechanism to add the parts to a local cache.

We have plans to expand the sharing of parts into an actual service managed by the SnapStore (eventually) where registering and updating a part would also build it for user opting to use that (instead of for example stage-packages). The possibility of caching the build locally has also been discussed, this broader to every part as it would enhance the builds when using the same part over multiple projects.

As I mentioned in a different reply to this post, we do have a mechanism to tell snapcraft where to look for all the parts, used mostly for testing. However, the people working on KDE Neon have already been using this as their alternate parts repository mechanism.

[bsutton]

@sergiusens

tell snapcraft where to look for all the parts, used mostly for testing

It would be good to see this documented and and refined for snapcraft users.

One of the biggest problems I’m having with snapcraft is in the turn around times with test iterations. If you then involve a remote part with a 30min cache refresh on the remote part wiki parts catalog things get even slower.

Having a ‘local’ remote part store would solve multiple issues.

[bsutton]

@sergiusens

An executable file in <rootdir>/snap/hooks/<hook-name>

An executable file installed by a part to `/snap/hooks/.

I’m not certain how this works nor was I aware of the two different methods.

Can you elaborate on how the two methods are defined. I’m familiar with dropping files into my /snap/hooks directory but I’m not certain which of the methods you mention this relates to and I don’t know how to do the second method.

Secondly as I understand hooks the hook file names MUST be ‘install’ and ‘configure’. If the snap has a pair of hooks and the part has a pair of hooks then isn’t one pair going to over-write the other pair?