Somehow installing both old and new versions of dbt_utils?

Lines 2 to 3 in 7f02d45

    
           - package: dbt-labs/dbt_utils 
        
             version: [">=0.6.0", "<0.7.0"]

This release appears to have resulted in this happening in my jobs:

2021-07-02 18:25:38.529544 (MainThread): Making package registry request: GET https://hub.getdbt.com/api/v1/calogica/dbt_date/0.3.2.json
2021-07-02 18:25:38.546599 (MainThread): Response from registry: GET https://hub.getdbt.com/api/v1/calogica/dbt_date/0.3.2.json 200
2021-07-02 18:25:38.546984 (MainThread): Making package registry request: GET https://hub.getdbt.com/api/v1/fishtown-analytics/dbt_utils/0.6.6.json
2021-07-02 18:25:38.594579 (MainThread): Response from registry: GET https://hub.getdbt.com/api/v1/fishtown-analytics/dbt_utils/0.6.6.json 200
2021-07-02 18:25:38.594948 (MainThread): Making package registry request: GET https://hub.getdbt.com/api/v1/dbt-labs/dbt_utils/0.6.6.json
2021-07-02 18:25:38.610934 (MainThread): Response from registry: GET https://hub.getdbt.com/api/v1/dbt-labs/dbt_utils/0.6.6.json 200
2021-07-02 18:25:38.611555 (MainThread): Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'end', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7efdaf5c61f0>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7efdaf619610>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7efd952bc310>]}
2021-07-02 18:25:38.611852 (MainThread): Flushing usage events
2021-07-02 18:25:38.634612 (MainThread): Found duplicate project "dbt_utils". This occurs when a dependency has the same project name as some other dependency.

Am I the only one?

Is it possible to make this an explicit instead of implicit dependency? I would rather have dbt_utils explicit in my packages.yml instead of being pulled by dbt_date.

Hi, do you have another package that's referencing the old fishtown-analytics repo? Sounds like you have another package that's also importiung dbt_utils but from a different repo, so dependency resolution doesn't kick in.

I will probably revert this update today, until folks are ready to update their packages, stay tuned

Reverted. Current version is now 0.3.1, dbt package hub should be updated shortly.

Re: explicit imports - the guidance I got from dbt Labs was to import dependent packages if macros are actually used in the package. If you're just shim'ing a macro for a platform, the recommendation was to use git submodules. I'll check in again with them to see if that thinking has changed!

Hi, do you have another package that's referencing the old fishtown-analytics repo? Sounds like you have another package that's also importiung dbt_utils but from a different repo, so dependency resolution doesn't kick in.

I did but this was the result after removing a redundant dbt_utils call (that I guess was the same version so it didn't fail? Was never sure why it worked) and changing my other fishtown packages to dbt-labs. What currently works is:

packages:
#  - package: dbt-labs/dbt_utils
#    version: 0.7.0
  - package: dbt-labs/codegen
    version: 0.3.1
  - package: dbt-labs/audit_helper
    version: 0.3.0
  - package: gitlabhq/snowflake_spend
    version: 1.2.0
# dbt_date includes dbt_utils
  - package: calogica/dbt_date
    version: 0.3.0

and that was only after rolling back dbt_date from >=0.3.0, which pulled 0.3.2, to 0.3.0

@davesgonechina you should be good now without pinning dbt-date, the current release is 0.3.1 which includes the previous reference to dbt-utils.

looks good, thanks for the speedy reply!