Proposal: Expose SNAPCRAFT_SNAP and SNAPCRAFT_PARTS environment variables

Rationale

Sometimes building a part requires access to files in other parts’ or in the snap/ directory like part’s installation prefix directory and part patches. This proposal suggests the following two environment variables to make these access easier.

  • SNAPCRAFT_SNAP : Points to the path of the snap/ folder
  • SNAPCRAFT_PARTS: Points to the path of the parts/ folder

Hi there, thanks for the idea, but for parts, I have to say that parts are supposed to build in isolation, if a part requires use of assets provided by another one, they are supposed to be staged and ensure ordering is correct by means of the after keyword.

I would like to know what user stories or use cases exist for exposing the snap directory though as that is mostly fixed assets that if modified during the lifecycle could cause strange behavior (as changing the source of truth does).

In my case I have some library parts that are statically linked to the main application part, such parts have less reason to be included in the staging phase and often broken when doing so(like the wx-config command of wxWidgets libraries which is a symbolic link to another file in the part’s install tree). Currently, I simply avoid staging all those parts and just pointing their installdirs to the configure script that requires them.

The normal way to handle parts that are only used during build is to add them like any other part, reference them from the depending part from $SNAPCRAFT_STAGE, and remove their unused files from the final snap using prime with a “not everything” parameter:

parts:
  static-library:
    ...
    prime: [-*]
  main-app:
    after: [static-library]
    ...
1 Like

As I mentioned formerly not all parts still work properly when being “moved” from their installation prefixes to the /stage directory, an additional fix-up will be required when such cases occurred.

Also for SNAPCRAFT_SNAP there has to be a place to store additional patches to be applied to the parts’ source tree after the pull stage to make it work properly, for example, some parts that are not relocatable, currently /snap/patches path has been used for such things and it would be better if we can access it easier than referencing it via $SNAPCRAFT_STAGE/../snap.

To add patches to a known location, use the dump plugin:

parts:
  patches:
    source: some/directory/in/your/source
    plugin: dump
    organize:
      patchfile.diff: some/known/directory/in/stage/patchfile.diff
    prime: [-*]

  application:
    after: [patches]
    override-pull: |
      snapcraftctl pull
      patch -Np1 < $SNAPCRAFT_STAGE/some/known/directory/in/stage/patchfile.diff
    ...
2 Likes