Remove the distinction between --select and --models flags when working with node types

[joellabes]

Describe the feature

It would be less confusing if all nodes were selectable using a single flag, instead of having to switch back and forth.

Describe alternatives you've considered

Getting over it

Additional context

I imagine it would make more sense to settle on --select and -s because they're more broadly applicable. The migration might be uncomfortable, but could be a slow-boiled frog in the same vein as config-version:

• A minor version of dbt where --select is the default version in the docs etc for new users and -m users keep going without any issues
• Some minor versions of dbt where -m users get a WARN during compilation
• A future version of dbt (maybe 1.0?) where -m is deprecated and no longer respected.

Or, just add -s as an alias and leave the old ones around forever; they're not really doing any harm!

Who will this benefit?

New users in particular (this confused me ~9 months ago), but it also just bit me again 😑.

Are you interested in contributing this feature?

Sure! I'm sure I could work it out by looking at how the -model alias is currently handled. Most of the work feels like it would be in the deprecation warnings

[jtcohen6]

@joellabes I agree! In all likelihood, I think we should:

• Switch all commands / tasks to use -s, --select
• Keep supporting -m, --models, forever, as an (undocumented) alias for -s, --select

There are two things we'll need to sort out before we do this:

Trivial: list

The list task / dbt ls command is the only one that supports both -m, --models and -s, --select, and they do slightly different things. Instead of -m and -s being direct aliases, --models xyz is functionally equivalent to --resource-type model --select xyz. I think we could deprecate --models and still have it perform that same functionality. We already do a good job today of raising an exception if --models is passed alongside either --select or --resource-type, since they're mutually exclusive.

Trickier: test selection

dbt test --models has a "magic jump" baked in, such that dbt test -m model_a really means, "Select all the tests that directly depend on model_a, i.e. dbt ls -s model_a+1 --resource-type test. It's a bit unintuitive, but it also enables really compelling syntax for "run and test model_a." But I think it _only_ makes more conceptual sense for test -m, i.e. execute tests that directly apply to a model, even if the tests themselves are not directly selected—whereas test -s`, to me, sounds like it should execute only the tests that are directly selected.

Before we fully switch dbt test -m to dbt test -s, I think we should first make the change outlined in #2891:

We could modulate the magic, and make it only select tests if all their parents are all the way present.

This still gets us the compelling syntax we'd want while handling the worst surprises. dbt test -s model_a model_b would run:

• any test named model_a or model_b
• any test that is defined on / directly depends on model_a, model_b, or model_a + model_b (but not, say, a relationships test between model_b + model_c)

I realize that, by saying this, I'm blocking a semantic change behind a meatier functional change—maybe it's not fair to use one as the forcing function for the other—let me know if you disagree! In any case, I think this is something we should seriously consider doing ahead of v1.0.

[joellabes]

I think you've explained the magic jump to me a couple of times in the past, but I get it this time! Thanks.

test -s, to me, sounds like it should execute only the tests that are directly selected.

by saying this, I'm blocking a semantic change behind a meatier functional change

I'd make a half-hearted argument that flags' meanings (especially short flags) can be anything we want them to be. The strongest argument to back this up is that dbt test --models my_custom_data_test selects that test, with nary a model in sight. It's never occurred to me that that's weird, because I was thinking of -m as the thing I type to make dbt do what I want, as opposed to deeply considering the flag's name.

Side note: realistically, this all only applies to custom data tests, right? Am I right that (for selection purposes) schema tests' True Names are the kwarg portmanteaus we all know and love? If so, then I doubt anyone is typing dbt test --models dbt_utils_source_not_null_where_tasks_tasks_datedeleted__isdeleted_1 on a regular basis. I think hope that the fact that someone is only ever selecting

• data tests, or
• schema tests that touch a model

glosses over a lot of the complexity. Having those two PLUS selecting a single instance of a schema test would probably be gnarlier to build a mental model upon.

For the record, I am on board with the magic modulation! But I don't think it has to block this. With that said, this isn't at all urgent, so if we wanted to put it on the backburner until after #2891 then I'd be fine.

Also, agreed that supporting -m forever is the right choice.

[jtcohen6]

Ok, I think all your instincts here are right! We should do this, and we should also do #2891; we should both before v1.0. Let's hold off on it for the moment, not on the backburner per se, but in the spirit of planning a number of nomenclature changes for the minor versions between v0.20 and v1.0.

[leahwicz]

• Already completed: if test depends on other tests then don't run it -> Run tests IFF all first-order parents are selected #2891

• Goal: Deprecate the models flag (still support it)

[jtcohen6]

@joellabes I'd love to get this in for v0.21. Is this still something you'd be interested in contributing? We can offer some helping hands along the way :)

[joellabes]

@jtcohen6 yep let's give it a whirl!

[jtcohen6]

@gshank I'd really like to prioritize this one and get it in for v0.21. This will go nicely with the more-consistent dbt source freshness and the net-new dbt build. The build command (in beta) currently uses --models instead of --select, which doesn't make a lot of sense!