Containing snap related assets to the snap directory

snapcraft
1

It isn’t quite sane to put snap-related files out of the /snap directory, I would like to request either:

  • Ignoring x- prefixed sub-dirs in the /snap directory for custom files.
  • Allow unused in /snap sub-dirs (will break stuff if snapcraft starts using them)
  • Other means that can improve this situation
2 Likes
2

I think this is probably where your request should be noted: How to deal with source code that has code in a "snap" directory?

3

That topic is slightly different, as it is a different kind of “snap” directory under the source tree, my problem is rather the custom subdirs under the snap directory.

4

This seems like an alternate approach to having snap/local as something snapcraft takes no ownership of.

@kyrofa mind weighing the options and proposing a final stance?

1 Like
5

I think having a directory that snapcraft owns except for a small slice is unclear. I would prefer that snapcraft owned a less conspicuous directory (.snap/ or .snapcraft/), leaving the snap/ directory free for use how the user sees fit (which solves the snapd issue as well and follows the convention laid out by other tools like Travis and Circle CI). However, I’m not sure that will happen. I’ve gone ahead and logged a bug for supporting folks putting stuff in snap/local/:

1 Like
6

What about parts, stage, and prime? Can we allow users to redefine these directories using environment variables like SNAPCRAFT_SNAP, SNAPCRAFT_PARTS, SNAPCRAFT_STAGE and SNAPCRAFT_PRIME? This allows projects to have a source tree hierarchy such as putting snap related files under /distribution/linux/snap{py}.

7

There are two different types of files that snapcraft cares about: the source files (e.g. snapcraft.yaml and custom local plugins) that should be version controlled, and the ephemeral build artifacts that shouldn’t be tracked and can be safely deleted (e.g. prime and stage). I agree that the source location should be relocatable (by environment variable or otherwise, e.g. to accommodate software that uses a snap/ directory for other purposes), but I don’t see a particular reason for the build directory to be tied to it, or for the various build directories to be separately configurable. Seems like it would make sense to have them as subdirectories under a single dir that is configurable (SNAPCRAFT_BUILD?).

As for defaults, I’d argue for snap/snapcraft.yaml and snap/build. Perhaps the snapcraft.yaml can override the default build directory, but with all the bits that snapcraft cares about living under snap/build it seems like there’s far less opportunity for accidental conflicts.

I don’t really like the snap/local approach – snapcraft should prefer to restrict itself to one subdirectory, rather than limiting the project in which it is a tenant to one subdirectory. Which other dirs does snapcraft care about today?

1 Like
8

I am not sure we are on the same page on the purposes of snap/local, it is not to put ephemeral content, but things that snapcraft will not intend to touch or own but the individual working on a project considers logically belonging to just snapcraft’s space, a common example of this is a wrappers directory. which would look like this:

parts:
    wrappers:
        source: snap/wrappers
        plugin: dump

The intention of snap/local is that it looks like this:

parts:
    wrappers:
        source: snap/local/wrappers
        plugin: dump

In order to not squat the snap namespace which is where we put snapcraft related content, such as:

  • hooks
  • gui related bits
  • snapcraft.yaml

At runtime, we put a .snapcraft directory in there which keeps track of all the parts and steps taken. This includes source change detection which was recently enabled (and caused most of the issues we’ve run into).

2 Likes