I feel, like this has been asked many times before, the last time i tried to use snap (almost 2-3 years ago) I’ve had the same problems. I am genuinely curious why this has never been addressed properly, surely these are relatively minor that could be addressed.
I have a source code repository that organizes multiple projects together with some shared dependencies. It’s a common development pattern w.r.t. project organisation, irrelevant to the subject, a flutter based application.
Basically, I have a layout like this:
.git
project_a/
project_a/snapcraft.yaml
project_b/
project_b/snapcraft.yaml
packages/
The different projects should produce separate snaps that can be installed independently of each other, to my understanding of snapcraft is that to access subdirectories the yaml needs to be organized in top directory of the project.
For clarity, I understand i can my make my own pull-step, but the problem is that when i place the yaml file in my project directory as I have done, snapcraft uses the current working directory where you call snapcraft build
as project directory in lxd, and since all the pull steps happen inside containers you simply loose access to adjacent parts of the file system.
However, by organizing the parts in the top-level directory (or the `/snap/ directory) with snapcraft.yaml. I can organize my parts to create the desired folder structure, with lxd now mounting the top-level directory as project folder, i can just access any subdirectory as I see fit, but the problem is that every part and application you define will be part of the same snap.
It just feels a bit that this that a lot of people have asked about monorepo support in the past, while a couple of small changes to snapcraft’s behavior would be enough. I’m not very enthusiastic about having to create symlinks or procedurally generating yaml files on demand to work around this problem, this doesn’t seem to fit the general ideology around snapcraft.
it’d be a lot easier if there were two extra command line arguments e.g. -c /opt/somewhere/
and --manifest /opt/somewhere/projecta/snapcraft.yaml
. The former to control the working directory for snapcraft command, the latter so you can give alternate names i.e. projecta.yaml, projectb.yaml, or organize them in subfolders like I’ve done.