SNOW-3227155: Feature to avoid installing \"boto\" dependencies does not work with package managers like \"uv\" and \"poetry\"

[ndamclean]

What is the current behavior?

SNOW-2107016: boto3 and botocore are unconditional dependencies in latest release 3.15.0 (#2323)

The implementation to avoid installing boto dependencies using the "SNOWFLAKE_NO_BOTO" environment variable does not work with package managers like "uv" and "poetry"

Commands to install package with uv: (also tested with poetry)

uv init
export SNOWFLAKE_NO_BOTO=true
uv add snowflake-connector-python

output (installs boto3 and botocore)

Initialized project `test`
Using CPython 3.12.11
Creating virtual environment at: .venv
Resolved 26 packages in 370ms
Prepared 10 packages in 426ms
Installed 25 packages in 30ms
 + asn1crypto==1.5.1
 + boto3==1.42.66
 + botocore==1.42.66
 + certifi==2026.2.25
 + cffi==2.0.0
 + charset-normalizer==3.4.5
 + cryptography==46.0.5
 + filelock==3.25.2
 + idna==3.11
 + jmespath==1.1.0
 + packaging==26.0
 + platformdirs==4.9.4
 + pycparser==3.0
 + pyjwt==2.11.0
 + pyopenssl==25.3.0
 + python-dateutil==2.9.0.post0
 + pytz==2026.1.post1
 + requests==2.32.5
 + s3transfer==0.16.0
 + six==1.17.0
 + snowflake-connector-python==4.3.0
 + sortedcontainers==2.4.0
 + tomlkit==0.14.0
 + typing-extensions==4.15.0
 + urllib3==2.6.3

What is the desired behavior?

Users of package managers like uv and poetry should be able to add the python snowflake connector without the additional boto dependencies.

This seems like the perfect use case for the "default extras" (PEP 771) proposal. However that is "draft" status only at the time of writing this ticket.

The boto library dependencies could be made optional extras in the next major release. But if only a small minority of users don't use AWS that may not be desirable.

How would this improve snowflake-connector-python?

Making these dependencies optional would avoid forcing users to install large SDKs they don't use and would allow for leaner deployments.

References and other background

No response

[sparkiegeek-slam]

This is what we use in pyproject.toml to force uv not to install the unnecessary bloat

[tool.uv]
# Override to remove boto - see https://github.com/astral-sh/uv/issues/9174 and https://github.com/snowflakedb/snowflake-connector-python/pull/2525
override-dependencies = [
    "boto3; python_version < '3.0'",
    "botocore; python_version < '3.0'",
]

[sfc-gh-sghosh]

Hi @sparkiegeek-slam,

Thanks for raising the issue. This is a known limitation of the current implementation

We've been able to reproduce the behavior you described — the SNOWFLAKE_NO_BOTO environment variable does not take effect when installing via uv or poetry, since these package managers install from pre-built wheels where boto3/botocore are already listed as unconditional dependencies in the wheel metadata.

uv init && export SNOWFLAKE_NO_BOTO=true && uv add snowflake-connector-python
Initialized project `sghosh`
Resolved 26 packages in 5.17s
Prepared 14 packages in 5.27s
Uninstalled 3 packages in 18ms
Installed 14 packages in 30ms
 + asn1crypto==1.5.1
 + boto3==1.42.66
 + botocore==1.42.66
 - certifi==2026.1.4
 + certifi==2026.2.25
 - charset-normalizer==3.4.4
 + charset-normalizer==3.4.5
 + filelock==3.25.2
 + jmespath==1.1.0
 - platformdirs==4.9.2
 + platformdirs==4.9.4
 + pyopenssl==25.3.0
 + pytz==2026.1.post1
 + s3transfer==0.16.0
 + snowflake-connector-python==4.3.0
 + sortedcontainers==2.4.0
 + tomlkit==0.14.0

This is a known limitation. We will work on eliminating it and will evaluate the best approach to make boto dependencies truly optional across all package managers.

In the meantime, please use the uv override workaround you mentioned:

Regarding the PEP 771 suggestion, it is currently in Draft status and not yet available in the Python packaging ecosystem.

[sparkiegeek-slam]

Hi @sparkiegeek-slam,

Thanks for raising the issue. This is a known limitation of the current implementation

We've been able to reproduce the behavior you described — the SNOWFLAKE_NO_BOTO environment variable does not take effect when installing via uv or poetry, since these package managers install from pre-built wheels where boto3/botocore are already listed as unconditional dependencies in the wheel metadata.

uv init && export SNOWFLAKE_NO_BOTO=true && uv add snowflake-connector-python
Initialized project `sghosh`
Resolved 26 packages in 5.17s
Prepared 14 packages in 5.27s
Uninstalled 3 packages in 18ms
Installed 14 packages in 30ms
 + asn1crypto==1.5.1
 + boto3==1.42.66
 + botocore==1.42.66
 - certifi==2026.1.4
 + certifi==2026.2.25
 - charset-normalizer==3.4.4
 + charset-normalizer==3.4.5
 + filelock==3.25.2
 + jmespath==1.1.0
 - platformdirs==4.9.2
 + platformdirs==4.9.4
 + pyopenssl==25.3.0
 + pytz==2026.1.post1
 + s3transfer==0.16.0
 + snowflake-connector-python==4.3.0
 + sortedcontainers==2.4.0
 + tomlkit==0.14.0

This is a known limitation. We will work on eliminating it and will evaluate the best approach to make boto dependencies truly optional across all package managers.

In the meantime, please use the uv override workaround you mentioned:

Regarding the PEP 771 suggestion, it is currently in Draft status and not yet available in the Python packaging ecosystem.

I think that should have mostly been directed at @ndamclean (OP)

[ndamclean]

Regarding the PEP 771 suggestion, it is currently in Draft status and not yet available in the Python packaging ecosystem.

@sfc-gh-sghosh I should have read that more carefully. My initial thought was that it would make sense to use package extras but then users would have to specify explicitly that they want boto instead of having that as the default.

I did a search to see if there was a way to specify "default extras" and found that PEP proposal.

Making boto packages an optional extra would seem reasonable to me, but if non-AWS users are a small minority I understand why you have gone with this implementation.

Can I leave this issue open? I think it's a bit of a pain point and is something to consider addressing in the future.

Thanks @sparkiegeek-slam for the suggested workaround!

[ndamclean]

@sfc-gh-sghosh P.S. I updated the ticket description to clarify that PEP-771 is still only a draft proposal.