Location to save global state

snapcraft
1

We call state tracking when we save information about what snapcraft is doing to package the snap.

Currently we have state tracking for parts. We put in there things like the source, the build and stage packages installed, and specifics of the plugin like the python and npm packages. It is saved in directories like parts/part-name/state. It is useful to identify when the snapcraft.yaml changes and a part needs to be cleaned, and later to record all that happened during the build and keep it in prime/snap/snapcraft.yaml for auditing and reproducible builds.

Now we need also a place to save information about global state. In here we will put things like the lxc image used during cleanbuild and the snapcraft version. We are also thinking of moving here build-packages, because they are installed before any part is pulled, thus affecting all the parts.

After a short discussion with @kyrofa, I think that a good place for this information would be in the file snap/state/global.

Update: following @niemeyer’s suggestion, the path will be snap/.snapcraft/state.

It’s good that it’s inside the snap directory, because if we put it outside it’s very likely that some projects will already have a directory called state. We then would have to use something more obscure, like .state or snapcraft-state. Another option was to put it in parts, but we have the same problem that we could have a part called state, and again would have to obscure the dir name by using something that is not valid as a part name. And the last point to support putting it in snap is that we will move the other snapcraft directories there (hopefully soon) in the future.

Now, I’m not sure what to do for projects that don’t have a snap directory, the ones that just put their snapcraft.yaml in the root. I guess it would be pretty harmless to create that snap directory, and it will be useful for the future migration of the other directories anyway.

I’m going to start implementing this right now to solve a little mess we have for tracking build packages. So if you have suggestions, or you think I missed a potential downside of using snap/state/global, please let me know.

2 Likes
2

I agree, I don’t see a downside to creating it. The long-term plan is to put all generated snapcraft stuff in there anyway.

3

Please don’t put it there, for multiple reasons. Perhaps the most important one is that this is internal state by snapcraft that shouldn’t be in people’s faces. Another one is that the name is way too general. What is a global snap state? Whatever it is, it’s definitely not snapcraft-related.

1 Like
4

Well, the parts, stage and prime directories are also internal to snapcraft. I see a state directory in the same category. So I’m not sure if for snap/state/global you are disagreeing with the snap, state or global part of the path, or the whole thing.

If you don’t want internals to be visible, and you want it to refer clearly to snapcraft, I think a .snapcraft directory is a good name. But I thought we had already agreed on putting everything on the snap directory.

5

snap/state/global doesn’t leave much for the imagination in terms of this being global snap state or not.

I suggest snap/.snapcraft.state for the purpose you want. The prime, stage, and parts terms are all unique to the build process, and they’re intentionally made visible to the user so that they can be inspected. Different case.

I’d also change the part-specific one to be .snapcraft.state inside the respective directory.

1 Like
6

works for me. But we probably need to make it a directory.

For now, everything I have in mind right now fits in a single file. But as we add things, it might make sense to put more files, I don’t know, something like snap/.snapcraft.state/lxc. That’s why we discussed about naming this first file global.

Also, we currently have those directories in parts/part-name/state which might make sense to move into snap/.snapcraft.state.

7

In that case I suggest snap/.snapcraft/{state,lxc,etc}

2 Likes
8

@elopio can we update the original post with the end result (adding a comment that you have done so). I can turn this into a wiki if that is required. This is so that in the future we can refer to this as a spec as well.

9

I added an update to the original post. Feel free to make it a wiki if you think it will be good.