it would be nice if snapcraft had something like .snapignore to filter out files that should never be in a snap. It has a builtin one, which isn’t exposed for tweaking afaik.
2 Likes
Yes to this, we have a built-in one which ignores certain parts of snapcraft when dealing with local sources to avoid recursion but that same logic can be used to add language or project specific ones through some sort of .snapignore.
1 Like
We already have language for each part with the specific purpose of including and excluding paths.
Isn’t that the same thing?
This is to cater for the source: . case and not copy in things to parts/<part-name>/src from . that should be ignored like __pycache__ and such.
We might as well try and read any existing .gitignore there, but it might be too much magic for a user.
That wouldn’t work because .gitignore is about source code, while snapcraft is about binary builds. So that file will list things which you want to see included.
My point, though, is that we already have a very flexible way to express rules for ignoring files in parts. Are we missing something on top of that, and if so what is it?
We have the stage and prime language in parts, yes. What we don’t have is something to deal with:
parts:
part:
source: .
plugin: python
$ ls
__pycache__
setup.py
So __pycache will never make it to stage or prime unless someone copies it into parts/part/install, but it will make it into parts/part/src as we have no language to prevent that. In that sense .gitignore is where you would filter out __pycache__ as it is not part of the sources.
How does that __pycache__ get there, well, maybe I ran that setup.py outside of snapcraft.
For what it’s worth, I am not advocating for the use of .gitignore, I am just trying to draw the full picture of what @chipaca wants a solution for.
The python example could be handled nicely in the python plugin out of the box if it were aware of pycache and *.pyc files.
That may not cover all use cases, though. @chipaca Do you have some examples of what kind of files you’d want to ignore?
Don’t hold too tight onto __pycache__, it is a controllable example and could very well be done by extending the plugin language 
FWIW this came up because we are (or were until yesterday) currently shipping a developer’s .swp file because they had a file open in vim while they were working on the snap. Snapcraft happily slurped up the .swp.
In this case all it leaked was the developer’s name and a bit of their laptop’s layout, but it could’ve been worse.
I see, so the issue is indeed when copying the source code, in the pull step. Yes, respecting existing ignore lists in that case sounds sensible (.gitignore, .bzrignore, etc). Might be worth having a look at the command line options of the tar command, and into the implementation of –exclude-vcs-ignores.
In addition we should also exclude well known unwanted files. The *.swp example is a good one.
I’d still vote against having some sort of .snapignore though. If we need to define that on the snapcraft side, we should have a setting on the part itself which defines what to ignore instead of asking people to put more content into their repositories.
1 Like
Any more thoughts on this? I’ve seen this a couple of times now, e.g. the entire Python virtualenv (only useful during development) and other temporary resources are copied to the part. Honouring the VCS (bzr and git) would probably cover most use cases.
1 Like