I have a snap that snapcraft v7 refuses to build, so I’ve been using v6 (by the way, would love to see that fixed). I tried to use snapcraft remote-build today and it failed to build. Looking at the logs it appears to be because it installs snapcraft v7 in the Launchpad builder, not v6. It doesn’t set the source channel for the builder at all. It means that I can’t build my snap at all using remote-build (slight lie: I can go edit the created snap in LP, make it use the 6.x/stable channel for snapcraft, and then re-start all my failed builds, but that’s not really a solution).
It seems reasonable to me that snapcraft install from the same channel in a remote-build as that being used locally, no? If that seems unreasonable, could this be configurable somehow?
Sorry, somehow I missed the previous report follow-up about it not being fixed. One simple way to build the nextcloud snap with Snapcraft 7 is to change the snapcraft package to snapcraft_legacy in the local plugins:
...
Priming php-customizations
+ snapcraftctl prime
Priming redis
+ snapcraftctl prime
Priming redis-customizations
+ snapcraftctl prime
Priming setup-https
+ snapcraftctl prime
Determining the version from the project repo (version: git).
The version has been set to '24.0.8snap1-dirty'
Snapping |
Snapped nextcloud_24.0.8snap1-dirty_amd64.snap
Thanks @cmatsuoka. Ultimately I just need to update my plugins to work in whatever new world that is v7, but that doesn’t change the fact that this is an issue. Are few enough people still using v6 that it isn’t much of a priority, though?
I’m planning to write some kind of generic package import redirector to handle the snapcraft vs snapcraft_legacy case for existing plugins, but until that’s in place the easiest way is to change that by hand. We have some hacks in place for snapcraft.plugins.v1 and snapcraft.plugins.v2, but this solution doesn’t scale to the entire source code.
One reason we’re dropping local plugins as they currently are is because people can access too much with them and that prevents us from refactoring internal code. They may come back in a different form, with access restricted to a well-defined public API.
Ah yes, the fact that it’s using a different version inside the managed environment is wrong, both versions should be exactly the same. Can you create a bug for that so we won’t forget to fix that?
