new command: dbt ls

[drewbanin]

List models selected by CLI args. Eg.

$ dbt ls --models salesforce.* --exclude salesforce_accounts
models/salesforce/salesforce_users.sql
models/salesforce/salesforce_contacts.sql
models/salesforce/salesforce_leads.sql
....

This will be especially valuable when dbt supports selecting models by tags, materialization type, etc, etc.

Great idea @emilielimaburke

[clrcrl]

I think I'd prefer the command to be list as opposed to ls, and for it to just return the model names.

$ dbt list --models salesforce.* --exclude salesforce_accounts
salesforce_users
salesforce_contacts
salesforce_leads
....

Maybe it could have a flag like --verbose that shows the fqn versions:

$ dbt list --models salesforce.* --exclude salesforce_accounts --verbose
salesforce.salesforce_users
salesforce.salesforce_contacts
salesforce.salesforce_leads
....

I personally am less interested in the file paths, especially since the file paths don't include the name of my own project.

I'm not sure what the ordering of the output should be. Probably alphabetical? But I can also imagine someone might want to see them in the order they appear in the DAG, but that gets tricky.

[drewbanin]

Really nice spec here, @clrcrl! Let's do it!

$ dbt list 
  --resource_type {model|source|...|default|all}
  --select {list of selectors}
  --exclude {list of selectors}
  --output {json|name|path|selector}

Available resource types:

• default:
  • model
  • archive
  • seed
  • test
  • source
• all:
  • default+
  • documentation
  • analyses
  • macros

Resource type labels:

• default
• all
• refable (everything in default except tests)

DEFAULTS:

• resource_type = default
• output = selector

OUTPUTS:

• For name/path/selector, sort alphabetically
• For json, use a dictionary indexed by node unique_id... sorting is not applicable. Assume output will be consumed programmatically

CAVEATS:

• The path output should return file paths to resources relative to the cwd
• The json output should return serialized ParseNodes (possibly a subset... we care about package name, tags, configs, depends_on, etc.... we care less about sql text). TBD if we normalize the json output across resource types... it's ok if these vary
• Provide a (hidden?) ls alias for list (is that ok?)
• If no resources are matched, exit with an error code (+ emit a warning?)
• We need to be conscious about the stdout here... supress the logger, push warnings to stderr, etc