setuptools Version Constraint in acryl-datahub and Security CVE Guidance – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: Dependency Conflicts and Security Vulnerability Management

Issue

The acryl-datahub package enforces an upper bound of setuptools<82.0.0 across all recent releases. This constraint can block security teams from satisfying scanner requirements that mandate a newer version of setuptools — for example, to address a reported CVE. The conflict arises because setuptools 82.0.0 removed the pkg_resources module, which is still required at runtime by several libraries in the DataHub dependency tree. Forcing a newer version of setuptools into an environment that runs acryl-datahub will cause runtime failures for ingestion jobs.

Error Messages

ModuleNotFoundError: No module named 'pkg_resources'

You Might Be Asking

Why does acryl-datahub cap setuptools below version 82?
Can I force setuptools>=83.0.0 to satisfy a security scanner requirement?
Does the CVE flagged by my scanner actually require setuptools 83 or higher?
Is there a safe interim path while the dependency constraint is being resolved upstream?
Which specific DataHub dependencies still rely on pkg_resources?

Solution

Understand why the constraint exists.
Setuptools 82.0.0 removed the pkg_resources module. Several libraries in the acryl-datahub dependency tree still import pkg_resources at runtime, including:
- stopit==1.1.2 — a threading timeout library used by the PowerBI connector
- sentry-sdk — a base dependency present in every install
- The great_expectations fork used for data profiling
- Transitive dependencies such as pytz, babel, and werkzeug
When any of these libraries are loaded under setuptools 82 or newer, they raise ModuleNotFoundError: No module named 'pkg_resources', causing ingestion jobs to fail. The upper bound was introduced as a deliberate safeguard after this breakage was observed in production.
Do not force setuptools>=82 in an environment running acryl-datahub ingestion.
Installing a version of setuptools outside the supported range may appear to succeed at install time but will cause runtime failures as soon as any of the affected dependencies are imported. The exact point of failure depends on which ingestion sources and plugins are active. This is especially relevant for environments running full ingestion pipelines (e.g., via Airflow or a scheduled executor).
```
# Do NOT do this in an acryl-datahub ingestion environment
pip install "setuptools>=83.0.0"

# Supported range as of recent acryl-datahub releases
# (Docker-based ingestion images enforce this floor)
setuptools>=80.10.1,<82.0.0
```
Clarify which CVE your scanner is flagging and verify the actual fix version.
Not all CVEs related to setuptools require version 83 or higher. For example, CVE-2025-47273 (a path traversal vulnerability) was patched in setuptools 78.1.1. Docker-based DataHub ingestion images already enforce setuptools>=80.10.1 as a lower bound, which covers that CVE. If your scanner is reporting a requirement for >=83.0.0, confirm the exact CVE identifier with your security team. It may be:
- A different CVE than the one patched in 78.1.1
- A scanner policy threshold rather than a hard requirement from the CVE advisory itself
Assess runtime exposure versus build-time exposure.
Some setuptools CVEs are build-time vulnerabilities affecting how source distributions (sdists) are packaged — not runtime vulnerabilities in the installed package. If the CVE in question is build-time only (e.g., involving sdist packaging of Unicode-named files and MANIFEST.in exclusions), consider the following:
- If your repositories install and run acryl-datahub for ingestion (e.g., emitting metadata, running connectors), you are not building sdists and are therefore not exposed to a build-time-only vulnerability at runtime.
- If your repositories build and publish Python source distributions that bundle sensitive files and rely on MANIFEST.in exclusions, the CVE may be directly relevant.
Pursue a risk acceptance for the CVE if your usage is runtime-only.
If your security team confirms that the flagged CVE is build-time only and your environments do not build or publish sdists, document a risk acceptance for the medium-severity finding. Use the following points to support the justification:
- The CVE is a build-time packaging vulnerability, not a runtime exploit.
- The affected package (setuptools) is used as a dependency resolver, not as application logic.
- Forcing setuptools>=82 would break production ingestion due to the pkg_resources removal.
- The DataHub engineering team is actively working to remove pkg_resources dependencies so the upper bound can be lifted in a future release.
Monitor DataHub release notes for removal of the upper bound.
The long-term fix requires migrating all affected dependencies away from pkg_resources, starting with replacing stopit with a library that does not use it. This is tracked as a dependency modernization task. Once completed, the setuptools<82 constraint will be removed in a future release. Check the DataHub changelog and GitHub release notes for updates.
```
# To check what version of setuptools is active in your environment
python -c "import setuptools; print(setuptools.__version__)"

# To check which installed packages still depend on pkg_resources
pip show acryl-datahub | grep -i requires
python -c "import pkg_resources; print([d.project_name for d in pkg_resources.working_set])"
```

Additional Notes

The setuptools<82.0.0 upper bound was introduced in early 2026 after setuptools 82 shipped and broke production ingestion environments. It applies to all recent releases of acryl-datahub, including v1.7.x and DataHub Cloud managed ingestion. Docker-based ingestion images enforce setuptools>=80.10.1,<82.0.0, which ensures coverage for CVEs patched in versions prior to 82 while avoiding the pkg_resources removal. The constraint affects all ingestion sources that transitively depend on pkg_resources — not just specific connectors — because sentry-sdk is a base dependency loaded for every ingestion run. Security teams evaluating this constraint should note that the DataHub engineering team is tracking removal of the upper bound as a prioritized dependency modernization effort; no ETA is available at this time.

Issue

Error Messages

You Might Be Asking

Solution

Additional Notes

Related Documentation