Importing boto3 1.42.88 triggers s3transfer ImportError (botocore.compat 'six')

[galuszkm]

Describe the bug

Importing the latest boto3 (1.42.88) triggers an ImportError in s3transfer, due to a missing 'six' import from 'botocore.compat'. This appears to be caused by s3transfer expecting 'six' in botocore.compat, which was removed in recent botocore updates (see related: boto/s3transfer#376). The error occurs even with default imports, making boto3 unusable with compatible s3transfer and botocore versions out of the box.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

boto3 (and s3transfer) should import without error when installed with compatible package versions, without requiring users to pin old botocore versions or patch s3transfer.

Current Behavior

When using the latest boto3 (1.42.88) which depends on recent botocore and s3transfer versions, importing boto3 results in the following error:

ImportError: cannot import name 'six' from 'botocore.compat' (.../botocore/compat.py)

This happens immediately on import due to a dead import that is no longer present in botocore.compat. See s3transfer issue #376 for the underlying cause: two unused s3transfer imports expect 'six' in botocore.compat, but 'six' was removed from botocore.compat as of v1.42.88.

Reproduction Steps

Create a project with the following pyproject.toml:

[project]
name = "s3transfer-import"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = [
  "boto3"
]

In a Python 3.11 environment, run:

import boto3  # or: import s3transfer

This triggers:

ImportError: cannot import name 'six' from 'botocore.compat' (.../botocore/compat.py)

Possible Solution

Ensure that new versions of boto3 do not depend on s3transfer versions that have dead imports of 'six' from botocore.compat. The s3transfer fix is to remove the two unused imports (see boto/s3transfer#376). Either update s3transfer dependency range or coordinate releases that mutually address this breaking change.

Additional Information/Context

This is directly related to boto/s3transfer#376 which describes and implements a fix for the root cause in s3transfer. The issue in boto3 arises because the dependency chain allows incompatible botocore/s3transfer versions to be installed together.

SDK version used

boto3 1.42.88, botocore 1.42.88, s3transfer (latest as of April 2026)

Environment details (OS name and version, etc.)

Python >=3.9, all operating systems; issue is version/dependency-related, not environment-specific.

[RyanFitzSimmonsAK]

Hi @galuszkm, thanks for reaching out. I'm having trouble reproducing the behavior you're seeing.

botocore.compat does import six : https://github.com/boto/botocore/blob/0db98ca4a6b8b783a0e1f17f767c288a53bd90c1/botocore/compat.py#L29

In 2022, the dependency on six was removed and botocore.compat was refactored to not rely on it : boto/botocore#2806. The next day, the import was readded for backwards compatibility : boto/botocore#2814.

botocore.compat hasn't been changed in five months, so I'm unsure what you mean by six having been removed in 1.42.88. Could you provide debug logs to help us investigate? You can get debug logs by adding boto3.set_stream_logger('') and redacting any sensitive information. Thanks!

[galuszkm]

Hi @RyanFitzSimmonsAK

Update: This was a local cache corruption issue, not an upstream bug. Closing.

After deeper investigation, I found that botocore.compat was never changed upstream — the six import is still present in the official PyPI package. The issue was entirely on my side, caused by an interaction between uv (Python package manager) and ruff (linter/formatter).

Here's what happened:

1. uv uses hardlinks to save disk space. When uv sync runs, files in .venv/lib/python3.x/site-packages/ are not copies — they are hardlinks pointing directly to uv's global wheel cache (~/.cache/uv/wheels-v5/).

2. By accident, ruff ran over the .venv/ directory — it wasn't excluded from the linting scope. Ruff saw from botocore.vendored import six as an unused import and auto-removed it, along with several other imports it deemed unused (OrderedDict, json, MutableMapping, etc.).

3. Because of the hardlinks, ruff's modification went straight through to uv's global cache. The cached botocore/compat.py for version 1.42.88 was silently corrupted.

4. Every subsequent uv sync in any project that depended on botocore==1.42.88 hardlinked to that same corrupted file. So every new virtual environment got a compat.py with the six import missing, causing s3transfer to fail on import.

The fix was uv cache clean botocore to purge the corrupted cache, and adding extend-exclude = [".venv"] to the ruff config to prevent this from happening again.

Apologies for the noise — this was not a boto3/botocore/s3transfer issue.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.