Part "after" changed behavior

snapcraft
1

In my package script I use “selective-checkout”. This has a pull were it gets some script that then gets staged. See https://github.com/metabrainz/picard-snap/blob/main/snap/snapcraft.yaml#L175-L187

The main part defines a

after: 
  - selective-checkout

as the selective-checkout script is used by the pull stage of the main part. This used to work. The docs for after say:

Ensures that all the <part-name>s listed in after are staged before this part begins its lifecycle.

So the main part was only pulled once selective-checkout had been staged.

But with snapcraft 7.2.7 this no longer works, the order of execution seems to have changed. Now all the pull stages run in order first. That means the main part’s pull fails because the selective-checkout’s stage had not yet been run. Is this a bug or intentional behavior?

1 Like
2

That’s correct, Snapcraft 7 will stage the dependent part after the build step runs when building core22 snaps. A workaround in this case could be to have a local copy of selective-checkout, and avoid staging patches (by applying them from $CRAFT_PROJECT_DIR/patches instead of $CRAFT_STAGE/patches).

2 Likes
3

Ok, thanks for confirming. Then I’ll restructure the build accordingly.

1 Like
4

@Lin-Buo-Ren I need to look into this and it might take a while until I have time to tackle this, but if I have something working in regards to snapcraft 7 + selective-checkout I’ll let you know :wink:

1 Like
5

Appreciated it, thanks!

NOTE: For some coincidence, I’m now refactoring selective-checkout, expect surprises :slight_smile: .

1 Like
6

Is there any reasoning for this new behavior?

7

@Lin-Buo-Ren I just had to look into this: I guess running selective-checkout in the build stage instead of pull does the trick. See https://github.com/metabrainz/picard-snap/commit/d84f939e75c136c38b482771c811b3aaad8e1a4f

IMHO this is still clean enough and works for me.

1 Like
8

This was originally intended to be part of the V2 plugin changes for core20, however the implementation kept the previous behavior. This was later addressed and then rolled back because it caused compatibility problems with existing core20 snaps, and the core22-step-dependencies build attribute was added to enable the behavior as opt-in. The idea is to decouple the pull step to work towards offline building, but we’re not quite there yet.

1 Like