add a filter field to rules and modules

[oconnor663]

It's been fairly common for me to use the build field to do something like

mkdir out && cp myfile out/

when I want to export only part of a directory. That feels pretty hacky, and it will be very inconvenient in builds that need to support Windows or even just cp -r (Mac requires the -R flag instead).

It would be better to have some explicit filter field. git add supports * and ** globs natively, so it shouldn't be too much trouble to expose this through Cache.import_tree.

My guess is that it would make sense to apply the filter step after export, which means that filter paths would be relative to the export dir rather than relative to the module root. That would save the user from duplicating the export path in the filter spec. The order of application of rule fields would then be:

1. build
2. export
3. filter

[oconnor663]

@olson-sean-k pointed out that "filter" is confusing. E.g. what does this mean:

filter: example.py

Is example.py supposed to in included, or excluded? Who knows. Instead, how about we call this "files"? That seems to work pretty well with all the different ways this attribute can be used:

files: example.py
files:
  - a.py
  - b.py
files: **/test*.py

Also, should we make sure it's an error if we end up matching no files? I feel like it should definitely be an error if you try to add a literal filename that's not there. Git might take care of that for us, actually.

[olson-sean-k]

I think files is a good name for this. I also agree that matching no files should be an error.

[oconnor663]

Ok I didn't think this through though: What if the argument to files: is a directory? Do you get everything in that directory? Maybe we should call it paths:? Or glob:? Edit: paths conflicts too closely with plugin fields like path in cp. Sticking with files.

[oconnor663]

https://phabricator.buildinspace.com/D30

[oconnor663]

675aac2