[CT-2129] [Bug] dbt --version hangs when access to PyPi is not available

[flyingTiemen]

Is this a new bug in dbt-core?

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

Current Behavior

When using dbt --version a check is done at PypI.org if a newer version is available.
In many compagnies access to the internet is restricted. In that case dbt --version does wait forever and never exits.

Expected Behavior

Make check at PyPi optional, or at least, timeout this check after some time in a proper way.

Steps To Reproduce

dbt --version without access to PyPi.org

Relevant log output

No response

Environment

- OS: any
- Python: any
- dbt: any

Which database adapter are you using with dbt?

No response

Additional Context

No response

[jtcohen6]

Thanks for opening @flyingTiemen!

Paraphrasing from a slack convo I had with @aranke @stu-k a few weeks ago:

• Better: We should add an aggressive timeout to the "latest" check / PyPI API call
• Best: We print dbt version info immediately, turn the PyPI check into an async/background process, and only return the "latest" info if/when it's ready
• Maybe: Give users the option of disabling the "latest" check / PyPI API call entirely. This might be especially relevant in cases where folks want to run --version programmatically. (There are other things we'd need to do to enable like, above all returning version info as a JSON blob instead of colorful pretty-printed text.)

I think the quickest quality-of-life improvement here would be adding an aggressive timeout (e.g. 1s) to this line:

dbt-core/core/dbt/version.py

Line 45 in b7884fa

resp = requests.get(version_url)

 resp = requests.get(version_url, timeout=1)

Would you be interested in contributing that quick change?

[flyingTiemen]

Tested the quick change, that works fine.

I'm new to contributing to a project on GitHub, I'm not sure if I can add. I'm also behind a firewall which makes access to GiHub a bit problematic (for cloning and commits etc).

[aranke]

Potentially a dupe of #6085

[jtcohen6]

I'm going to mark this as a good_first_issue, at least for the simplest "better" solution: add a retry timeout of 1 second :)

@aranke Should we keep #6085 open, and more narrowly scoped to the "best" solution proposed above — yielding information as it becomes available? (I think that's what your approach in #6083 was after)

[aranke]

Yup, sounds good @jtcohen6!