Allow to ignore a list of RegEx expressions in layer contract

[iagocanalejas]

Fixes #44

[seddonym]

Thanks so much for this, looking forward to reviewing it. Before I merge it I'll want to make sure there are tests - if you have time to do that, go ahead! Otherwise I'll add them when I get the chance.

[seddonym]

Thanks for the great PR!

This has helped clarify my thinking about how to approach this feature. To begin with at least, I think it would be better to implement this as a top-level configuration, rather than on a contract-by-contract basis.

The main reason for this is that because the layers contract uses find_shortest_chain to analyse the graph. Because that includes indirect imports, the excluded modules might still trigger a contract failure.

I think the better approach is to remove the ignored modules from the graph altogether before analysing anything. This is easier to do globally across the whole run, as it means we don't need to add the modules back afterwards.

To help with this, I've today released a new version of Grimp that has a remove_module method (v1.0b11).

So, building on your PR, here's what I think we should do:

1. A top level configuration called exclude_modules which takes one or more modules that should be removed from the graph after it is built.
2. The setting should support pattern matching, though personally I feel it would be better just to use * wildcards but not support regular expressions, as they can be difficult to read and we probably don't need that kind of power here. I'm open to persuasion though! The fnmatch might be good for that.
3. The main implementation code would be in importlinter.adapters.building.GraphBuilder, which I imagine would remove any matching modules after the graph is built, using graph.remove_module.
4. GraphBuilder would need to support a new exclude_modules parameter, to see how to get this from the top level configuration take a look at how include_external_packages is handled.
5. We'd need to include documentation for the exclude_modules.
6. We'd need tests.

Let me know what you think of that approach, and also whether or not you'd like to contribute any code towards it. If not, I'll list you as a contributor anyway for your help so far.

Thanks again - and let me know if you have any questions.

[iagocanalejas]

1. Seems fine to me as this configuration could be useful for more contracts.
2. Right, simple pattern matching is easier to configure.
3. Don't really dive to much in the implementation so i will trust you in that
4. Easy
   5&6. Obviously

I don't know if i will have much time in the near future but will try my best to do some advances.

[seddonym]

Cool, stay in touch. If I end up implementing it I'll let you know too.