I’ve created a ccache remote part to make all depending parts use ccache automatically to reduce snap build time, however recently I noticed that the subsequent build frequently indicate:
Updating pull step for ccache (source changed)
and all depending parts are cleaned as a result.
IMO, snapcraft should verify if the remote part is really changed.
This is due to the fact that, without a base specified, if you don’t specify a source it defaults to source: .. If anything in that directory changes then snapcraft considers the pull step to be out of date. If you specify a base you’ll see that snapcraft no longer uses this default source (although remote parts become more difficult to use).
I fail to see how this is related to a remote part, can you clarify?
What are the difficulties in detail?
The remote part you’re using there uses the nil plugin with no source specified, which means it defaults to the root of the project. As a result, any change in the root of the project is picked up as a change to the part’s sources.
That remote parts no longer exist when using bases. You’ll need to snapcraft define them and copy them in.
In another thread it was suggested that adding a (possibly empty) override-pull scriptlet to that part using the nil plugin would work around the bug in snapcraft 2.x. It turns out this isn’t enough, and to really work around the problem I had to add a dummy empty source directory and point the part to it.
I heard that snapcraft is deprecating remote parts, is there any (upcoming) features that supersede it? Copy the part definitions isn’t really ideal.
Two features, which in combination should cover most use-cases of remote parts: extensions (essentially curated remote parts defined within snapcraft itself), and stage-snaps. The latter will allow someone to package up e.g. a working gstreamer and then allow other snaps to unpack that gstreamer snap within it. This also means it doesn’t need to be built every time.