snowflake-connector-python: Error on 2.0.3: ssl_wrap_socket_with_ocsp() got an unexpected keyword argument 'key_password'

Please answer these questions before submitting your issue. Thanks!

  1. What version of Python are you using (python --version)? 3.7.2

  2. What operating system and processor architecture are you using (python -c 'import platform; print(platform.platform())')? Mac OS X

  3. What are the component versions in the environment (pip list)? https://termbin.com/28i3

  4. What did you do? If possible, provide a recipe for reproducing the error. A complete runnable program is good. Install dbt with 0.10.3 and snowflake-python-connect 2.0.3. dbt debug on any dbt project that uses snowflake and it will show

ssl_wrap_socket_with_ocsp() got an unexpected keyword argument ‘key_password’

  1. What did you expect to see? No error

  2. What did you see instead?’ ssl_wrap_socket_with_ocsp() got an unexpected keyword argument ‘key_password’

  3. Can you set logging to DEBUG and collect the logs?

import logging
import os

for logger_name in ['snowflake.sqlalchemy', 'snowflake.connector', 'botocore']: 
    logger = logging.getLogger(logger_name)
    logger.setLevel(logging.DEBUG)
    ch = logging.StreamHandler()
    ch.setLevel(logging.DEBUG)
    ch.setFormatter(logging.Formatter('%(asctime)s - %(threadName)s %(filename)s:%(lineno)d - %(funcName)s() - %(levelname)s - %(message)s'))
    logger.addHandler(ch)

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 3
  • Comments: 27 (9 by maintainers)

Commits related to this issue

Most upvoted comments

Hi, why was this closed?

We can’t pin requests just to accommodate snowflake-connector-python, and thus we’re now broken on latest.

We also noticed that 1.9.0 was removed from PyPI without any notice, yet is still listed in the release notes. This broke our build process and forced us to upgrade. It’s considered extremely dangerous to remove packages after they’ve been published, and the lack of transparency is even more unsettling.

This is extremely unprofessional for a product used in production.

I have fixed the issue with the newest urllib3 and will be pinning it much less aggressively for the next release.

Sorry about removal of 1.9.0. That was our mistake and will not happen again.

That’s simply not enough. You need to update the PyPI page. You need to declare that it was removed, and you need to describe why. It’s unacceptable.

Last working version we had was 1.9.0 and you broke us when you removed it. Every version since then was broken with the Azure BlockBlobService error, which is only resolved with newest version 2.0.3, which then has an absurd urllib3 requirement, which requires us to downgrade requests.

It’s a library. It is not appropriate to lock your transitive dependencies.

This issue was closed because the issue can be addressed by upgrading all to the latest following snowflake-connector-python needs.

Incorrect.

We’re awaiting a version that is compatible with the latest version of requests.

While waiting for 2.0.5, I’ve resorted to the following requirements when running in a lambda.

azure-common<2.0.0
azure-storage-blob<12.0.0
requests==2.21.0
urllib3==1.24.3
snowflake-connector-python==1.9.1

@keller00

Libraries can inform minimum constraints, but should generally not enforce maximums, leaving it up to the system administrator to lock versions if the library ends up not being compatible.

I’m hoping this is what you mean by “pinning it much less aggressively” 😃

Thanks for the update!

I’m having the same issue. 2.0.3 fixed the Azure issue. I’ve tried pinning urllib to 1.24.3, pinning azure-storage-blob to 2.1.0, and pinning snowflake-connector-python to older versions with no luck.

I didn’t change urllib. Just pinned these 2 versions.

azure-storage-blob==2.1.0 snowflake-connector-python==2.0.2

Let’s hope it’s fixed. I wasted a good hour yesterday trying to figure out why my Lambda stopped working only to find this issue and roll back the urllib3 version that adding the S3 connector lib had changed.

ok, we’ll update the doc and attempt to support the latest urllib3 and requests.

Decided to skip 2.0.5 and release 2.1.0 in the first week of December.

The 2.0.4 release notes do not reflect anything related to this issue.

The 2.0.4 patched for workaround. More complete solution would be in 2.0.5

There is no milestone attached to this issue.

Attached recently.

1.9.0 continues to be listed on the release notes with no mention of it being removed, or why.

v2.0.5 will have the doc update.

2.0.4 already appears to have a py3.x issue as per above.

Can you please elaborate this? We are not aware of py3 specific issue. The above one doesn’t sound like Py3 specific but both py2 and py3.