The future of dbt utils

[joellabes]

TL;DR

I think that the dbt utils package is trying to do too much, and that it should be more focused. Below is a proposal to break it into more logical chunks.

Once you've read it, I'd love to know your answers to any and all of these questions:

• Do you agree with the proposed split lines (move cross-db macros to Core/adapters, keep tests and utility macros in the one repo, move insert_by_period materialization to the experiments repo)? If not, how would you break it up, if at all?
• If you're a package maintainer with a dependency on dbt utils:
  • Would moving the cross-db macros into the various adapters/dbt Core mean you could break your dependency?
  • Is that valuable to you one way or the other?
• Anything else you want to say about how the package should be managed, in general?

Background

By a wide margin, dbt utils is the most-used package in the dbt Hub - over 1/3 of active projects installed it over the last week. However, it is actually many packages in one:

• Useful tests which aren’t built into dbt Core:
  • extensions to builtins (eg relationships_where, unique_combination_of_columns),
  • generic tests for data (eg accepted_range, not_constant),
  • generic tests for table shape (eg equal_rowcount, cardinality_equality)
• Macros to abstract away complex work: star, pivot, get_column_values
• Cross-database macros which are most useful to enable compatibility in other packages - we don’t recommend end-users use these themselves
• A catchall for experiments: specifically insert_by_period, a custom materialization which fills a niche as best it can but relies on hacky behaviour to work.

These different packages are... different, both in target users and rate of iteration. If we pull them out into their own packages, they can each do their own thing without interfering with one another.

What would this look like?

Cross-database stuff

This is slow-moving, stable code, and is depended on by most packages which aim to support all database adapters. We'd move the default implementations of these into dbt Core, and the overrides into the various database adapter repositories. For example, bigquery__except would move to https://github.com/dbt-labs/dbt-bigquery.

By doing this, we hope that many package vendors could drop their dependencies on utils altogether, which makes version resolution easier.

Macros and tests: one package or two?

Although macros and tests are different on paper, they both stay true to the spirit of dbt utils: "install this, and you'll get a bunch of useful functionality for free". For that reason, I personally lean towards keeping them together. There's an argument to be made that they could be split out to dbt_utils and dbt_extra_tests or something - if you want to be the one to make that argument, I'll hear it!

Experiments

This is not clearly cut. Some options, from least favourite to most favourite:

• Instead of being a centralised thing, it could be split out to various DB-specific utils packages, e.g. dbt-labs/redshift and Montreal-Analytics/dbt-snowflake-utils. I don't really think this is practical - Snowflake utils isn't a Labs-supported project, doesn't even do this sort of thing, and there aren't equivalent packages for BQ/PGSQL.
• [Feature] The insert_by_period materialization should graduate to part of the main project dbt-core#4174 promises that one day this behaviour will get easier; maybe it hangs out in utils until that day comes.
• We could make a new package dedicated purely to custom materializations. Tidy, but a bit overkill?
• We already have https://github.com/dbt-labs/dbt-labs-experimental-features, but this isn’t a package itself so much as a holding area for multiple dbt projects. The good news is that as of dbt Core 0.20.0, it's possible to install a subdirectory via git.

I believe that everything inside of dbt-utils should be usable by the "core four" adapters (Redshift, Postgres, Snowflake and BigQuery). There is a wonderful community contribution pending to add Snowflake compatibility to this materialization, but nothing for BQ or Postgres.

For this reason, my preference is to move it to the experimental features repo, where it's available to the community but the compatibility and maintenance expectations are clearer. Even if it was compatible with all four adapters, it's still a hacky setup – albeit useful! – and not at the same level of resilience as the rest of the project.

Migrating safely

I imagine that we'd implement a similar deprecation process to the not_null_where and unique_where macros for a time: dbt utils would display a deprecation warning and then dispatch to the macro's new home, before being removed in a future minor version (or maybe dbt utils 1.0.0?!)

Looking forward to hearing everyone's thoughts!

[simon-stepper]

Thanks for the write-up Joel! From the perspective of a team lead of a rather small-ish dbt deployment (2 people team, ca. 200 models).

General thoughts

• We see dbt_utils as a core part of dbt and would not think about using dbt without this package. Reading your breakdown of the different parts of dbt_utils, this refers to the additional tests and the macros to abstract away complex work. I sometimes wondered why this isn't part of dbt_core already, as we see it so closely connected and as an integral part of our dbt usage.
• The cross-database macros and the experimental features did never really concern us as they don't relate to our usage of the package. So a split up here would definitely make sense.

Cross-database

Including the respective implementations in the database adapters seems right to me. We never referenced them in our code anyways and as you start using multiple packages, the dependencies can become a bit messy. Huge thanks to the effort of all package maintainers in getting new releases out as soon as possible!

Macros and tests

We "vote" to keep this together. From the perspective of discovering new dbt functionality, it's easier to install a single package and then discover more functionality within it. Let's assume we started using dbt_utils because of the pivot macro and then discovered the new testing possibilities. Not sure if we would have searched the whole hub for more packages.

Experimental

No strong opinions here. However, having an experimental feature in such an integral package seems a bit odd, as noted by you.

[ilmari-aalto]

Thanks for having the initiative @joellabes !

We use the helpful macro and testing side of dbt-utils, and would "vote" to keep them together, or even move to dbt-core, if that's a possibility:

Some tests we use:

• dbt_utils.unique_combination_of_columns
• dbt_utils.expression_is_true
• dbt_utils.cardinality_equality

Some macros we use:

• dbt_utils.surrogate_key
• dbt_utils.star
• dbt_utils.union_relations
• dbt_utils.get_column_values
• dbt_utils.date_spine
• dbt_utils.unpivot
• dbt_utils.log_info

When it comes to experimental features like insert_by_period for better or worse we've built our own 😛

[mmeasic]

And let's not forget about the spark-utils. Personally, these brought a lot of confusion sometimes, since we run both dbt and dbt-spark projects at the firm.

Did you have anything in mind for it?

Regarding the 4 important adapters, I think it makes sense to move cross-db macros to their database adapter repositories, keeping the default implementation in the core.

[joellabes]

Great point on spark-utils - I'll touch on it in a response to Joe below!

[jtcohen6]

Joel does indeed touch on this below in more detail, so just to add/summarize very quickly:

If every "cross-db" macro, currently in dbt-utils and shimmed by spark-utils, were to move into dbt-core and adapter plugins — including dbt-spark + dbt-databricks — then spark-utils would no longer be an essential piece of the puzzle. (We might still want to keep that package around, to shim higher-level macros that don't make sense in core/plugins, or other Spark-specific utilities)

[fivetran-joemarkiewicz]

Thanks for this thoughtful writeup @joellabes! I wanted to jump in on the fun and add my thoughts to this thread. 😄

Do you agree with the proposed split lines (move cross-db macros to Core/adapters, keep tests and utility macros in the one repo, move insert_by_period materialization to the experiments repo)? If not, how would you break it up, if at all?

dbt-utils has become a behemoth in itself and I definitely see the value in splitting the various functions of the package into distinct use cases. With that, I completely agree with this initiative and have a few focused thoughts I wanted to share.

• I really like the idea of folding the cross-db macros into dbt. I have often wondered who else uses these macros other than package maintainers, and seeing from your post it looks like that may just be the case!
• I definitely say you should keep the macros and tests together. While they do inherently different jobs in the context of a dbt project, I see them fitting in as useful tools for the everyday Analytics Engineer. I like to think of them as a hammer and nail. They are distinct objects, but are used together to effectively build a strong and stable dbt project. Okay, I promise that was my one and only analogy in this post.
• For the "core four" adapters I see the macros folding in very nicely and really like the idea of them being slow moving, stable code that is built into dbt. With that, @mmeasic got me thinking about spark-utils and how dispatch overrides would work with macros that fold into dbt core/adapters? 🤔 I imagine this is possible, but curious if dispatching operates differently within dbt-core versus packages?
• Is there a possibility that this happens again in 5 or so years? Maybe the experimental package grows wildly and distinct use cases that don't fit into the other util packages are discovered. Would new packages be created for these other distinct use cases?

These are my initial thoughts, but will be sure to post any updates in this post if any more come to me.

If you're a package maintainer with a dependency on dbt utils:

• Would moving the cross-db macros into the various adapters/dbt Core mean you could break your dependency?
• Is that valuable to you one way or the other?

In my case it would not allow us to drop the dbt-utils dependency. I did a quick search this morning and found that we use the cross_db_utils in every one of our source packages, and leverage the other macros/tests within the sql, web, jinja_helpers, and schema_tests in the majority of our modeling packages. That being said, I still think it would be extremely valuable to fold the cross_db_utils macros into dbt-core/adapters. Although, I do have sweaty palms thinking about what/if changes would need to be made to our packages to account for the cross_db_utils being folded into dbt-core/adapters ✋😨✋.

If these macros are able to be easily dispatched from dbt-core/adapters then this would be no problem! However, I struggle to see this being an easy lift as we explicitly call out dbt_utils when we use these macros. If we are going to retain dbt_utils for the macros/tests then wouldn't there be a conflict if we declare dbt_utils for these cross_db_utils if they move int dbt-core/adapters? Therefore, I have a feeling this will require an update wherever these cross_db_utils are referenced. Please correct me if I am wrong (I hope I am wrong here 🤞). If I am not, then this will require a massive maintenance effort to update all of our packages.

Anything else you want to say about how the package should be managed, in general?

I stand behind this initiative and like the idea creating more distinct use case packages. The dbt-utils package as it stands is quite large and I can imagine a first (or multiple) time user can be a bit overwhelmed. If the users are now working within a more focused version of the package then I can see the user experience improving and maybe even feel encouraged to contribute to the package?! That is a stretch maybe haha but I like the thought!

A more general (but still related) question I have is around package dependency issues. The great thing about dbt-utils right now is there is only one package version you have to worry about. However, if we then hypothetically break this into two, three or more packages down the line then I could see a new issue arise around dependency and version issues across these various utility packages. What are your thoughts around improving this experience for users? I have seen a lot of questions with our package users who experience dbt run failures due to package dependencies being off. It would be great if there was some matrix or tool that could be leveraged by users to help navigate the package ecosystem and ensure they are using the appropriate versions across the board. This may be better for a more focused Issue/FR, but something to think about if the plan is to separate this package into multiple packages.

[joellabes]

• For the "core four" adapters I see the macros folding in very nicely and really like the idea of them being slow moving, stable code that is built into dbt. With that, @mmeasic got me thinking about spark-utils and how dispatch overrides would work with macros that fold into dbt core/adapters? 🤔 I imagine this is possible, but curious if dispatching operates differently within dbt-core versus packages?

@jtcohen6 tells me that if we put the default__ versions of the macros into dbt Core, and the adapter__ overrides into the various adapters, everything will just work, in the same way as you can today override something like create_table_as (default, snowflake.

"Shim packages" would become significantly less necessary, and if the spark-utils stuff moved into the spark adapter, then you'd just call {{ dateadd(...) }} (or {{ dbt.dateadd() }} if you want to be pedantic). dbt would pick up the adapter-specific variant if available, or fall back to the default implementation if not.

• Is there a possibility that this happens again in 5 or so years? Maybe the experimental package grows wildly and distinct use cases that don't fit into the other util packages are discovered. Would new packages be created for these other distinct use cases?

The era of tossing stuff with no other home into utils is over. As the most immediate example, consider the forthcoming macros to support metrics SQL generation; they're going into a dedicated dbt_metrics package, not a new subfolder in utils.

The experiments repo is actually a repo full of individual dbt projects, so if you want insert_by_period and another future package, you'd install them both separately. Will we accidentally wind up with another junk drawer somewhere else? I hope not, but human nature makes me not rule it out 😬.

I do have sweaty palms thinking about what/if changes would need to be made to our packages to account for the cross_db_utils being folded into dbt-core/adapters [...] wouldn't there be a conflict if we declare dbt_utils for these cross_db_utils if they move int dbt-core/adapters?

I hope that this will be as easy as find and replace dbt_utils.dateadd with dateadd for each of the impacted macros. As for conflicts, hopefully that's clarified by the {{ dbt.dateadd() }} examples above but to make it explicit: once they're in the Core/adapter projects they would no longer belong to the utils namespace so there wouldn't be conflicts.

maybe even feel encouraged to contribute to the package

Agreed - packages are a great place to get started with OSS contributions!

[what to do about dependencies if it's split up, a matrix of compatibility]

This is a multi-parter which boils down to "hopefully it's OK!"

• This should reduce dependencies, because if you're not using any of the sql-generating macros or tests, then you'd no longer need to declare a dependency on utils at all
• In a post-1.0 world, packages can be much more liberal with their require-dbt-version config, which means there isn't a mandatory cycle of releases every 3ish months with the next minor release of dbt Core, so people only need to do releases when there's something to release.
• We should still only need a single dependency on utils for both sql generation and tests. If we did wind up splitting those into a package each, then it might get a bit hairy, but better than the olden days for the above reasons.

I have thought about something like a "describe your ideal package setup and we'll work out the compatible versions for your packages.yml file" tool but haven't taken any action on it yet. Would definitely welcome a separate issue for that sort of thing!

[jtcohen6]

On the note around sweaty palms during the migration, and worrying about macro/package conflicts after we move cross-db macros: I think we could offer a "compatibility" version of dbt_utils, which buys time and breathing space for an easier migration.

Let's imagine we've moved all cross-db macros into dbt-core + adapter plugins by v1.1.0. Then we (dbt_utils maintainers) could just offer a passthrough, so that calls to dbt_utils.hash don't suddenly start failing:

-- dbt_utils/macros/cross_db_utils/hash.sql
{% macro hash(field) -%}
  {{ return(dbt.hash(field)) }}
{% endmacro %}

Or for even more breathing room, and backwards compatibility with dbt-core v1.0, we could continue to "vendor" the code in both places, using the dbt_version context variable as a conditional check:

-- dbt_utils/macros/cross_db_utils/hash.sql
{% macro hash(field) -%}
  {% if dbt_version.split('.')[1] >= 1 %}
    {{ return(dbt.hash(field)) }}
  {% else %}
    {{ return(adapter.dispatch('hash', 'dbt_utils') (field)) }}
  {% endif %}
{% endmacro %}

{# NOTE: everything below has since moved to dbt-core + adapter plugins, and will be removed from this package in a future version! #}
{% macro default__hash(field) -%}
    md5(cast({{field}} as {{dbt_utils.type_string()}}))
{%- endmacro %}

{% macro bigquery__hash(field) -%}
    to_hex({{dbt_utils.default__hash(field)}})
{%- endmacro %}

That way, Fivetran's packages could keep calling dbt_utils.dateadd, and then switch over to dbt.dateadd (or just dateadd!) at a time of their choosing, without needing to perfectly line up the web of interdependencies.

[noel]

I see so far there is a preference to keep macros and tests together, but I think the fact that we have tests in multiple places can be confusing to new users. Today we have tests in core, utils, and dbt-expectations. I realize that they are not the same maintainer, but from a new user's perspective, they are looking for "testing" and do not realize this difference exists.

One suggestion would be to merge tests in utils to either core or dbt-expecations.
just my $0.02

Aligned on the rest.

[joellabes]

Today we have tests in core, utils, and dbt-expectations

It's a fair point! My gut feeling is that we solve this with improved discoverability, not trying to combine the three. Looking ahead a year or two, I assume that more and more packages will come onto the scene, with different API styles (by which I mostly mean naming schemes of tests, arguments etc, but also what problems do they take on). As the ecosystem continues to bloom, it won't be practical to constrain development.

I did spend some time thinking about whether dbt utils should get out of the testing business altogether. I even went so far as to look at whether dbt-expectations had drop-in replacements for all of the current ones, but decided it wasn't practical. Mostly because there wasn't much overlap, and where there was it would have required some gymnastics (e.g. a simple not_constant test would need to be something like expect_column_unique_value_count_to_be_between with a min boundary of 2 and no upper bound).

I don't have good answers for how we improve that discoverability yet - ideas welcome!

[jeremyyeo]

Imho, we should try to nail down what the dbt-utils package wants to be (this seems like the attempt at doing so 😀) - and perhaps a dbt utility package should exist to help analytics engineers be "lazier" with "chore" type work - it should help them write less code when they want to union all relations, when they want to pivot tables, when they want to join N dim tables into a single one, etc.

Tests

If the tests are important enough, then we should promote them into dbt-core rather than maintaining two different sets of tests between the packages that dbt Labs maintains. Would this make dbt-core itself harder to maintain though? 🤔

Cross-database stuff

I think these should be implemented in the adapter's themselves and then dispatched just like how each adapter currently have their own implementations of say the core create_table_as() macro today.

Experiments

Probably uncontroversial to say but they probably have no business being here - just get rid of them 😬

---

Once we remove the above categories, then likely we are left with our guiding principle of "helping analytics engineers do chores with less code".

[jtcohen6]

I've really appreciated reading each and every response so far! Thank you all for engaging so quickly and thoughtfully :)

As @joellabes rightly pointed out to me, there's a recurrent motif:

I sometimes wondered why this isn't part of dbt_core already

even move to dbt-core, if that's a possibility:

merge tests in utils to either core or dbt-expecations

If the tests are important enough, then we should promote them into dbt-core

Why core?

• Macros for common, reusable functionality that differs across databases can be implemented in dbt adapter plugins, where they will work "out of the box," and where they can also be subjected to more rigorous testing. (We're working now to significantly improve the testing capabilities available to adapter plugin maintainers.)
• Users get access to these macros out-of-the-box, just like other macros in the global_project. It's slightly more convenient to reference the macro as dateadd instead of dbt_utils.dateadd (though there are good reasons to prefer the latter for clarity).
• Overriding global macros is simpler than overriding package macros. You don't need to understand macro dispatch or include an adapter decorator (default__). (I will say that the ergonomics around this have improved in recent versions, and I'd still like to improve them substantially further: [CT-112] Better UX for macro dispatch dbt-core#4646.)
• Changes to macros are more clearly tied to dbt-core versions, rather than needing to worry about breaking changes in the matrix of dbt-core + dbt-utils minor versions. (Again, less of a concern after dbt-core v1.0, given the commitment to backwards compatibility.)

Why not core?

• Barrier to contribution: To contribute to dbt-utils today, you just need to be a fairly skilled user of dbt. Even the integration tests are "just" a dbt project. To contribute to dbt-core or adapter plugins, you need to also know enough to set up a local development environment, to feel comfortable writing/updating Pythonic integration tests, ... It's definitely a higher barrier. I'm also committed to doing whatever we can to lower it.
• Maturity: Adding these macros into dbt-core is a solid way to "lock" them in. For any macros with more frequent changes, such as the addition of new arguments, a commitment to backwards compatibility necessitates some pretty ugly code! And for any macro that hasn't risen to this level of maturity (such as insert_by_period), dbt-core isn't the right place.
• Macro discoverability: Arguably, the macros in dbt-core are less discoverable than the ones in dbt-utils (by virtue of its thorough README). Global macros are generally treated as "internal" methods, relevant if you want to alter underlying dbt behavior, rather than go-to utilities. This is a problem we need to solve with better product features—such as by documenting macros, and surfacing those descriptions in the context of development—and in the meantime, we'd need to solve it with significant manual effort over at docs.getdbt.com. To that end...
• Teaching new users about macros/packages: The fact that so many projects install dbt_utils feels like a good thing—especially if we can slim down dbt_utils to an actually manageable/sustainable collection of "utilities." In the process, users are prompted to learn about packages (an essential dbt feature), explore other available packages, and realize that anything written in dbt_utils is something they fully have the power to write themselves, in their own projects. (That's not the case for most code in dbt-core + adapter plugins.) In particular...
• You can write your own generic tests! I like that custom generic tests live in a few different places today (dbt-utils + dbt-expectations), because I like empowering users to realize that they can write their own—and not feeling constrained by what's available out of the box. I'm not sure we'd be sending the right long-term signal by moving all of the generic tests in dbt-utils into dbt-core.

So, if I had my druthers...

What I'd want to move into dbt-core and adapter plugins:

• Cross-database macros, depended on by other macros / other packages for cross-database functionality but rarely called directly by end users. This feels pretty uncontroversial.
• Generic tests for "standard" use cases. The prime example for me is equality (we use it everywhere!); perhaps also expression_is_true. Something like cardinality_equality feels like an extension/modification of the "standard" behavior (equality), so I'd be inclined to have that live in a separate package—but I'm open to disagreement :)

Macros we wouldn't move to core/plugins:

• True utilities. I'm thinking date_spine, star, union_relations. These may depend on cross-database macros to work; if we move those into core + adapters, they should "just work" on most (all?) databases. These macros are a little bit clever, and they require running introspective queries in order to work; that pattern is something we increasingly recommend on an "only as you need it" basis. I'd rather users intentionally opt into using them, with awareness of the trade-offs involved. If we decided that moving these into dbt-core really is the right move, I'd almost rather stick them in a separate global package, similar to Python utils modules.
• Use cases better achieved via real dbt-core functionality. We obviated the need for not_null_where by supporting a where config for all generic tests. We've also removed the need for log_info thanks to new logging in v1.0, which includes a timestamp in every stdout log line. If a dbt_utils macro offers a half-decent workaround for something we'd really rather support with a change to dbt-core, I'd prefer to leave it in dbt_utils for the time being.

[joellabes]

I agree with all of this except for

Generic tests for "standard" use cases. The prime example for me is equality (we use it everywhere!); perhaps also expression_is_true. Something like cardinality_equality feels like an extension/modification of the "standard" behavior (equality), so I'd be inclined to have that live in a separate package—but I'm open to disagreement :)

• equality: when you say "we use it everywhere", do you mean in the context of testing dbt packages? It doesn't feel like a test that would be super common to use in an analytics context, compared to the other builtins, and I'm not sure that it makes sense to ship a test that is mostly for package validation inside of dbt-core.
• expression_is_true: my gut feel is that if this was the fifth built-in test, people would be less likely to go looking for other packages, and assume that this is the only escape hatch - most tests could just be expression_is_true if you tried hard enough.

If I was picking a generic test to promote, I'd lean towards accepted_range as the fraternal twin of accepted_values.

[joellabes]

I had a fun call with @dbeatty10 this morning where he also pushed on the logic around which things belong in dbt Core and which belong in dbt utils as legitimate utilities. For the record, here's where we landed:

Code in dbt utils should be useful even if there was only one database engine in the world. If JoelDB took over 100% of the dbt market, it would still be useful to have a one-line implementation of pivot instead of having to write all the introspective code yourself¹. By contrast, if we only had a single database, then all of the cross-compatibility stuff like "which order are these arguments in", "what does JoelDB call integers" would be redundant (in the same way as we don't have to dispatch select), which means those things should live at the adapter level and be defined in dbt-core.

If/when someone needs to add a new cross-db function to dbt-core, they would go through the standard PR process, which might mean it's 3 months until it's fully available. In the meantime, the package maintainer would ship the macro in their package, and they could remove that code once the next minor version of dbt-core shipped. dbt-utils isn't a training ground for new cross-db macros before they "graduate" - they would go directly into Core, which is safe due to all the very robust testing capabilities we have now! New utility macros (e.g. #617) would be and still are welcome in dbt utils.

¹ I would, of course, implement an excellent pivot function natively in JoelDB, making this redundant.

[clrcrl]

just came here to say that you are doing the lord's work joel and jeremy — keep going down this path, tysm

[leoebfolsom]

I've gathered from this discussion:

• I should learn more about cool stuff I can do with dbt_utils.
• there are new types of generic tests in dbt-core!
• contributing to a package is easier than contributing to dbt-core, and I should try it out.

Anyway, breaking up dbt utils sounds reasonable to me, a relatively new user of dbt. Thanks all!

[joellabes]

A couple of other standardisation projects we should keep in mind as we rocket towards 1.0:

• anything that takes *args for multiple inputs instead of a list should be updated (e.g. safe_add just bit me)
• we need to standardise the dates stuff (e.g. bigquery is returning datetimes instead of dates, which makes the metrics package messy (link 1, link 2 NB: those links won't work outside of dbt Labs for another couple of days)

[vinodsugur]

Team, I just need your opinion on enhancement of dbt_utils.equality which will be inline with following code
compare_table. This will add following enhancements:

• Driving table for comparison: This could be the model or the compare model. This might be helpful for scenario's in which a table is further enhanced from stage with additional attributes. In addition, would also like to combine this with ignore columns list.
• Column map: for mapping different columns in between model entity and compare model entity. There is a possibility of column renaming.

Let me know your views.

[edwrand]

This may have been previously mentioned, but adding more description on package dependency version requirements in the error logs would be super helpful. Recently ran into this issue with dbt-utils:

DependencyException Version error for package dbt-labs/dbt_utils: Could not find a satisfactory version from options: ['>=0.7.0', '<1.1.1', '>=0.8.0', '<0.9.0', '>=0.8.0', '<0.9.0', '>=0.8.0', '<0.9.0', '>=0.7.0', '<0.9.0', '>=1.0.0', '<2.0.0'] DependencyException

This results from adding the dbt-audit-helper package. More info in the log would be useful to trace back the dependency.

[dbeatty10]

Agreed!

Here's an issue on that topic that you can subscribe to:
dbt-labs/dbt-core#4775