Validate `require-dbt-version` before validating dbt_project.yml schema

[clrcrl]

Describe the feature

In the rare occasion that we change the spec of dbt_project.yml, the errors around this can be pretty confusing. We should consider changing the order of validation to make this nicer.

Example

At the moment if you have:

required-dbt-version: ">0.17.1"
config-version: 2

And your run this with 0.16.1, you get back:

Encountered an error while reading the project:
  ERROR: Runtime Error
  at path []: Additional properties are not allowed ('config-version' was unexpected)
Encountered an error:
Runtime Error
  Could not run dbt

I think it would be a very small, but nice touch, if instead we checked the require-dbt-version first, and then the schema, so this is the error you get:

Running with dbt=0.16.1
Encountered an error while reading the project:
  ERROR: Runtime Error
  This version of dbt is not supported with the 'acme' package.
    Installed version of dbt: =0.16.1
    Required version of dbt for 'acme': ['>=0.17.1']
  Check the requirements for the 'acme' package, or run dbt again with --no-version-check

Encountered an error:
Runtime Error
  Could not run dbt

I feel that the second error is way easier to understand. Obviously not everyone will have a require-dbt-version config, but it’s a nice behavior for those that are doing the right thing 🙂

Describe alternatives you've considered

Doing nothing :)

Additional context

I think the config-version error comes from the initial read of dbt_project.yml, which precedes our ability to check the dbt version. So maybe a little gnarlier to do this than expected.

Who will this benefit?

Anyone working on dbt in a team, that needs to keep dbt versions in sync across many computers

[beckjake]

This is a great idea, I've marked this as a "good first issue", but that doesn't mean "easy"! It's mostly a matter of pulling the various pieces together and should be pretty easy to test - it's going to work or it won't! I'm happy to help out with this if anyone wants to take it, or I will just do it whenever it's prioritized.

Here's my initial thoughts on how to solve it:

Currently, the process is:

• load the project file as yaml
• run the renderer over the loaded data
• validate the schema of the rendered project file
• parse the version
• instantiate a project object
• call validate() on it, which checks the --no-version-check CLI flag and conditionally validates that the versions match
  • on failure, include the project name in the message

We need to move version parsing and validation to be earlier, before we validate the file schema. One place I think would make a lot of sense for that is in Project.render_from_dict.

The nice thing about that is that at this point in the code, you can be sure that there's a name field (which you'll want for error messaging), and you have the rendered but not parsed/validated form of the required version field, if it exists.

You'll have to do some type checking, pull in the version-parsing from from_project_config (so _parse_versions), and write something that looks a lot like validate_version but isn't a method (you don't have a Project yet). I think those are the important parts.

The change also means that we can't just check --no-version-check like we do currently, but that's ok! Just move it into a flag in dbt.flags, it should basically do what USE_CACHE does.