Split up node selection

[beckjake]

Describe the feature

Per the discussion in #2203, we should split the current test selection into parts:

• node selection
• DAG construction

This solution must account for ephemeral nodes!

This will be the basis for a few interesting future changes:

• dbt run+test
• enforce only running a test where all its dependencies have been selected
• Direct child model selector #2052 - N-child selection
• advanced node selection

Describe alternatives you've considered

We can try to bolt those onto our existing framework.
We can avoid changing how node selection works.

Additional context

Not database specific

Who will this benefit?

This is mostly useful for whoever ends up implementing the dependent features.

[Raalsky]

💯 🚀

Maybe we should switch current selector to tokenization/grammar preprocessor and AST-based logic? I'm thinking about providing a formal grammar for node selection syntax and work around processing the tree of operations instead of mixing selection logic/tokenization etc. Then just apply it to nodes or tests with different semantics. At the top are tools like lex and yacc.

• more info about Yacc and Lex in Python (David Beazley 🚀): https://www.dabeaz.com/ply/ply.html
• series about simple AST: https://ruslanspivak.com/lsbasi-part1/

[drewbanin]

hey @Raalsky - cool idea! I think it could be sensible to use a proper parser in the future, but in general, I don't think the use-case requires it. The command line is a constrained programming environment, and it's probably not an ideal place to define deeply nested sets of selectors.

I'm happy to keep this in mind for the future -- maybe something like this would make more sense if we added new operators with complex precedence/associativity rules in the future?