Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Incorrect dependency causes older version of dbt-core to be installed #340

Closed
2 tasks done
htpaf opened this issue Oct 29, 2024 · 3 comments
Closed
2 tasks done
Labels
awaiting_response bug Something isn't working

Comments

@htpaf
Copy link

htpaf commented Oct 29, 2024

Is this a new bug?

  • I believe this is a new bug
  • I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

pip install dbt-snowflake==1.8.4
causes dbt-core 1.8.7 to be installed.

Expected Behavior

pip install dbt-snowflake==1.8.4
should install dbt-core 1.8.8 as this is the latest version available.

Steps To Reproduce

  1. Install Python 3.10.12 with venv support.
  2. python3 -m venv --clear --upgrade-deps env
  3. source env/bin/activate
  4. pip install dbt-snowflake==1.8.4 -vvv --no-cache-dir

Relevant log output

...
...
Collecting dbt-core>=1.8.0 (from dbt-snowflake)
  Obtaining dependency information for dbt-core>=1.8.0 from https://files.pythonhosted.org/packages/ac/97/f5fe35037be344888abe713b71dfd57f76abeb240c299e530e06001e27de/dbt_core-1.8.8-py3-none-any.whl.metadata
  Created temporary directory: /tmp/pip-unpack-96j22jvy
  https://files.pythonhosted.org:443 "GET /packages/ac/97/f5fe35037be344888abe713b71dfd57f76abeb240c299e530e06001e27de/dbt_core-1.8.8-py3-none-any.whl.metadata HTTP/1.1" 200 3879
  Downloading dbt_core-1.8.8-py3-none-any.whl.metadata (3.9 kB)
...
...
INFO: pip is looking at multiple versions of dbt-core to determine which version is compatible with other requirements. This could take a while.
Will try a different candidate, due to conflict:
    dbt-snowflake 1.8.4 depends on dbt-common<2.0 and >=1.0.4
    dbt-adapters 1.7.2 depends on dbt-common<2.0 and >=1.11
    dbt-core 1.8.8 depends on dbt-common<1.11.0 and >=1.0.4
Collecting dbt-core>=1.8.0 (from dbt-snowflake)
  Obtaining dependency information for dbt-core>=1.8.0 from https://files.pythonhosted.org/packages/81/01/67e9acf51e5b5326649066bc3ffc39dfe520dc5683bf980ab3abb7151a71/dbt_core-1.8.7-py3-none-any.whl.metadata
  Created temporary directory: /tmp/pip-unpack-h8gvyud1
  https://files.pythonhosted.org:443 "GET /packages/81/01/67e9acf51e5b5326649066bc3ffc39dfe520dc5683bf980ab3abb7151a71/dbt_core-1.8.7-py3-none-any.whl.metadata HTTP/1.1" 200 3924
  Downloading dbt_core-1.8.7-py3-none-any.whl.metadata (3.9 kB)

Environment

- OS: Ubuntu 22.04.5 LTS
- Python:3.10.12
- dbt-adapters: 1.7.2

Additional Context

I believe the issue is that dbt-adapters specifies >=1.11 in its requirements. It's difficult for me to determine whether the problem originates from dbt-snowflake, dbt-adapters, or dbt-core, but since dbt-core and dbt-adapters are supposed to have a relationship with all adapters, I concluded that dbt-adapters is likely the cause of the direct dependency conflict.

@htpaf htpaf added bug Something isn't working triage labels Oct 29, 2024
@amychen1776
Copy link
Contributor

Hello @htpaf, I'm curious about your use case for installing 1.8.4 vs. 1.8.7 rather than just the stable version of 1.8.

@htpaf
Copy link
Author

htpaf commented Dec 16, 2024

@amychen1776

Hello @htpaf, I'm curious about your use case for installing 1.8.4 vs. 1.8.7 rather than just the stable version of 1.8.

I want to set up a repeatable build.
I want to use dependency caching.
I do not want different code to execute in different environments at random, as we typically verify in one environment to be more sure it works in production environments.

pip freeze is used in this case. The setup is inspired by https://pypi.org/project/pip-tools / https://github.com/jazzband/pip-tools (though not actually using it).

@amychen1776
Copy link
Contributor

amychen1776 commented Dec 16, 2024

Looks like this was due to an issue we had on our side where we ended up having to pin the version. This has been resolved and should work now so I'm closing out this issue. If you see it again, please feel free to open the issue again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting_response bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants