SNOW-217037: Restrictive dependencies breaking projects

[avikaps]

Please answer these questions before submitting your issue. Thanks!

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

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

3. What are the component versions in the environment (pip freeze)?

asn1crypto==1.4.0
azure-common==1.1.25
azure-core==1.8.2
azure-storage-blob==12.5.0
boto3==1.15.18
botocore==1.18.18
cachetools==4.1.1
certifi==2020.6.20
cffi==1.14.3
chardet==3.0.4
cryptography==2.9.2
google-api-core==1.23.0
google-auth==1.23.0
google-cloud-core==1.4.3
google-cloud-storage==1.32.0
google-crc32c==1.0.0
google-resumable-media==1.1.0
googleapis-common-protos==1.52.0
hvac==0.10.5
idna==2.10
isodate==0.6.0
jmespath==0.10.0
msrest==0.6.19
numpy==1.19.3
oauthlib==3.1.0
oscrypto==1.2.1
pandas==1.1.4
protobuf==3.13.0
pyasn1==0.4.8
pyasn1-modules==0.2.8
pycparser==2.20
pycryptodomex==3.9.8
PyJWT==1.7.1
pyOpenSSL==19.1.0
python-dateutil==2.8.1
pytz==2020.4
requests-oauthlib==1.3.0
rsa==4.6
s3transfer==0.3.3
six==1.15.0
snowflake-connector-python==2.3.4
snowflake-sqlalchemy==1.2.4
SQLAlchemy==1.3.20
urllib3==1.25.11

4. What did you do?
   deploy it on Google Cloud functions as the Cloud Functions VM has the pre-installed with the listed packages : https://cloud.google.com/functions/docs/writing/specifying-dependencies-python
   But the has the package version 'requests==2.24.0' is causing this issues the the dependency in the build, as it is still requires 'requests<2.24.0' version

A complete runnable program is good.

5. What did you expect to see? requests==2.24.0 has been release quite some time back, please update the dependency

6. What did you see instead? code broke as it failed to clear the dependency

7. 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)

File "/env/local/lib/python3.7/site-packages/pkg_resources/init.py", line 791, in resolve raise VersionConflict(dist, req).with_context(dependent_req) pkg_resources.ContextualVersionConflict: (requests 2.24.0 (/env/lib/python3.7/site-packages), Requirement.parse('requests<2.24.0'), {'snowflake-connector-python'})

[sfc-gh-mkeller]

Hi @avikaps

Sorry for the inconvenience, but supporting the newest requests version is non-trivial as we add our own security on top of theirs.

Is it possible for you to pin the newest version we support in your own requirements file to downgrade the default package version?

[avikaps]

Hi @sfc-gh-mkeller

I tried downgrading the requests version explicitly in the requirement.txt file but since the Cloud Functions comes with the pre-installed dependencies, it's highly unlikely to downgrade that version.

Since we're trying to get data from SF on demand using these server less functions and we got this issues in our production pipeline environment. Are there any work-arounds or any other connector(s), that we can use just to make sure it works ?

Also, If you guys are trying to fix this issue what will be the tentative timeline that we can expect ?

Thanks,
Avi

[cfinkenstadt]

@sfc-gh-mkeller this OCSP security added is actually a problem when attempting to coexist with any non-trivial application that uses requests in its own right.

A fresh install of conda python 3.6 fully upgraded to latest releases, results in this while installing the snowflake-connector-python:

Installing collected packages: asn1crypto, oscrypto, requests, azure-core, requests-oauthlib, isodate, msrest, azure-storage-blob, jmespath, botocore, s3transfer, boto3, pycryptodomex, azure-common, snowflake-connector-python
  Attempting uninstall: requests
    Found existing installation: requests 2.24.0
    Uninstalling requests-2.24.0:
      Successfully uninstalled requests-2.24.0
Successfully installed asn1crypto-1.4.0 azure-common-1.1.25 azure-core-1.8.2 azure-storage-blob-12.5.0 boto3-1.15.18 botocore-1.18.18 isodate-0.6.0 jmespath-0.10.0 msrest-0.6.19 oscrypto-1.2.1 pycryptodomex-3.9.9 requests-2.23.0 requests-oauthlib-1.3.0 s3transfer-0.3.3 snowflake-connector-python-2.3.5

Successfully uninstalled requests-2.24.0

[sfc-gh-mkeller]

I understand @cfinkenstadt
Our team has been investigating how to fix this issue in the near future, but for now we cannot just remove OCSP.
If you had any suggestions I'd be happy to present it to the team

[cfinkenstadt]

I have two suggestions, one of which is related to our work-around,

For the version-specific issue: vendor requests 2.23, similar to the way snowsql does its own packaging away from the system-supplied modules.

For the "breaks everyone else" especially boto3 and normal requests access, we use something close to this work-around

# preserve original behavior
import requests.packages.urllib3.connection as connection_
SAVED_CONNECTION = connection_.ssl_wrap_socket
# hello, Snowflake
import snowflake.connector
import snowflake.connector.errorcode
from snowflake.connector.errors import DatabaseError, ProgrammingError
# restore original behavior
connection_.ssl_wrap_socket = SAVED_CONNECTION

This suggests that over in snowflake.connector https://github.com/snowflakedb/snowflake-connector-python/blob/master/src/snowflake/connector/connection.py#L406 use a context manager to SET upon entry, and RESTORE upon all exits, the desired OCSP mode in ssl_wrap_socket.

[sfc-gh-mkeller]

After thinking on this for a few days, I realize that the context manager way you describe might run into concurrency issues and could cause the same issue.
Vendoring is the option that we have been planning on trying out, just to be transparent with all of you my only concern is package size. Vendoring all of requests might put us over the package size limit of AWS Lambda, which is so important to a lot of customers.
Nonetheless; stay tuned, I'll get to this issue soon!

[johnrhageman]

Just want to add myself to the list of people impacted by this. Google does not appear to offer any way to manually override the version of their pre-installed dependencies in GCP functions. This means our functions that use snowflake-connector-python are now failing. I did try to specify a version in requirements.txt and redeploying the function, but get the same error.

(requests 2.24.0 (/env/lib/python3.7/site-packages), Requirement.parse('requests<2.24.0')

Edit:

I manually added requests==2.23.0 to my requirements.txt and re-deployed. Added a debug log to output the version of requests, and it showed 2.23.0. However, I still get the same error above about <2.24.0.

[cfinkenstadt]

@sfc-gh-mkeller understood about the concurrency issue using a context manager, it was also a concern of mine but my Python-fu is not yet enough to understand the threading concurrency model in Python.

[cfinkenstadt]

Does AWS Lambda support anything but deflate inside the ZIP file archive? (A trick I learned awhile ago in another context, not AWS lambda, though.)

[sfc-gh-mkeller]

It looks like you can do over 50 MB

If the deployment package is larger than 50 MB, you must use Amazon S3.

according to https://docs.aws.amazon.com/lambda/latest/dg/python-package.html

[jacopoch]

This could be merged in the dependency chaos ticket here: #284

Maybe voicing a bit more the issue with the dependencies will get something moving eventually 👍

[natekupp]

also wanted to add a +1 to this (and to #284) - would be fantastic to see this connector break out optional dependencies as package extras and relax constraints wherever possible, especially given the more strict new pip dependency resolver.

Thanks in advance!!!

[sfc-gh-mkeller]

Since we vendored requests in #557 I'd like to close this issue.
The monkey patching is now only performed inside of our vendored version on requests.
Please re-open this ticket if you you have any more issues, or concerns related to this ticket!