Maybe? Move dbt-date and dbt-expectations dependencies here

[fivetran-jamie]

Currently, some of our packages have dependencies on calogica's dbt-date and dbt-expectations packages. When there is a breaking change update to one of these packages, we need to update the version ranges across multiple packages' packages.yml files. For example, we have these 3 issues to increase the range of dbt-date:

• [Feature] Update dbt-date version range dbt_zendesk#109
• [Bug] dbt_expectations <0.9.0 dependency dbt_google_ads_source#44
• [Feature] update dbt-expectations version range dbt_hubspot#117

and I expect more issues to come in from:

• intercom
• shopify

It would be more efficient if we only had to make this update in one place (ie in fivetran_utils). However, this would mean that every single package would have a dependency on these external packages, even if they don't need them. The main con of this would be that we would either need to

a. update the Does this package have dependencies? section of every single package's README to include dbt-date and dbt-expectations (and to uptick the package version ranges everytime we upgrade), OR

b. rethink the Does this package have dependencies? section of the README. Perhaps this section would just link to the dependency matrix in the fivtetran utils README.

So maybe it's not worth it to do this, but maybe it is...

[fivetran-joemarkiewicz]

Another major con I see with this approach is that for every minor release of dbt-date or expectations we would also need to create a minor update to fivetran_utils. This means that 0.4.x would need to become 0.5.x after the dbt-date/expectations update. 😱 This would mean we would then need to update every source package to point to a new version of fivetran_utils. Unfortunately, this would explode the LOE from updating the dependency in one package, to needing to update nearly all the packages.

We discussed in standup yesterday that the best solution would be to ideally automate this update process. Primarily focusing on the cascading nature where the breaking change in the source will need to be breaking in the downstream dependent packages. In order to do this, we will need to apply this update manually but make note of the parts that may be automated so we can then streamline this effort when it happens in the future.

[fivetran-joemarkiewicz]

Closing out this feature request as previously discussed it would likely not be a great idea to include another dependency within this project.