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.
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
Indeed. This should also apply to the cleanbuild tarball (LP: #1661064).
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
. 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
prime language in
parts, yes. What we don’t have is something to deal with:
__pycache will never make it to
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.
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.