Sometimes, sometimes, declarative is not enough, one needs to get out of convened norms and do ones own thing.
To solve that we previously introduced these three primitives:
install. They lived around the
build step of a plugin’s lifecycle where
prepare would run before the
build logic of a plugin,
build would replace this logic and
install would run after the
build logic of a plugin.
Many problems were solved with this, but it is not clear from the get go what and when things will happen.
With scripting in mind, we additionally introduced the concept
version-script which would run at the end of the
prime step where the script would be required to
echo the string of what the version would be set to. Again, useful, but not clear. Added to that, we introduced a magic
version which when set to
git would do some automatic magical version tricks with git’s annotated tags.
Taking a step back, this is what we should have done and may make its way bit by bit.
Of the current steps a
part can have today:
build are implemented by the plugin, we will be introducing a backwards compatible change and adding a new step a plugin can implement, so that the lifecycle steps for are part become:
Instead of having random keyword names for which you have to know live around the
build step we will make it so that you can:
pull, replacing the logic of the plugin’s
build, replacing the logic of the plugin’s
install, replacing the logic of the plugin’s
stage, (TBD replacing the core logic of how files are migrated to
prime, (TBD replacing the core logic of how files are migrated to
Instead of have a
version-script and a
grade-script you will be able to call:
From any of the scripting entry points defined before.
Some projects are already well defined and to have to yet again define things in
snapcraft.yaml is a cumbersome and error prone process, to address that we will introduce a new
plugin concept orthogonal to the building plugins that would allow you to consume this metadata and set things like the
To illustrate better, metadata plugins would be named something like this:
Which will have a sole purpose would be to consume metadata and pass it on to snapcraft. There will be a more design oriented post for this specific one so people can get into the nuts of it, but didn’t want to leave it out from the big picture of this whole change.