attempt to pin setuptools

[adamsachs]

Unticketed

Description Of Changes

Fixes some build issues that started to make our CI fail due to upstream changes in setuptools to no longer ship with pkg_resources: see okta/okta-sdk-python#496 and https://github.com/pypa/setuptools/blob/main/NEWS.rst#v8200 for more context. we don't use pkg_resources ourselves directly, but some of our dependencies do, transitively.

This is a temporary fix to get our CI unblocked. #7328 will be a much-needed, more holistic update to our build/packaging pipeline.

Code Changes

• pin setuptools to 80.10.2 (which still includes pkg_resources) in all of our build pipelines
• ensure that no-build-isolation is set in all of our build/compile stages, to avoid some of our dependencies that build from source automatically using the most recent setuptools in their isolated build environment and failing, e.g. https://github.com/ethyca/fides/actions/runs/21839395886/job/63019453233

Steps to Confirm

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ready	Preview, Comment	Feb 9, 2026 11:26pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
fides-privacy-center	Ignored		Feb 9, 2026 11:26pm

[greptile-apps]

Greptile Overview

Greptile Summary

These changes attempt to stabilize CI/package/docs builds after upstream setuptools stopped shipping pkg_resources, by pinning setuptools to 80.10.2 and adding --no-build-isolation so isolated builds can’t silently pull a newer setuptools.

Most updates are limited to CI workflows, Docker build steps, and Nox’s install check. One additional runtime dependency change (scylla-driver bump) is included in requirements.txt, which appears unrelated to the stated goal and should be split or reverted to keep the PR focused and reduce upgrade risk.

Confidence Score: 3/5

• This PR is likely safe once the dependency scope is corrected and the setuptools pin is enforced more reliably.
• Core intent (avoid new setuptools/pkg_resources breakage) is reasonable and mostly localized to build tooling, but the PR currently includes an unrelated runtime dependency bump (scylla-driver) and uses exact pinning in pyproject.toml that can break source builds; Docker/docs pinning may also be overridden without constraints.
• requirements.txt, pyproject.toml, Dockerfile, docs/fides/Dockerfile

Important Files Changed

Filename	Overview
.github/workflows/cli_checks.yml	Pins setuptools and installs build deps before pip installing fides with --no-build-isolation to avoid upstream setuptools/pkg_resources breakages.
.github/workflows/publish_docs.yaml	Adds explicit setuptools pin + build deps and installs editable fides with --no-build-isolation; intended to stabilize docs build against isolated builds pulling newer setuptools.
.github/workflows/publish_package.yaml	Changes CI package publish workflow to install a pinned setuptools version instead of upgrading to latest.
Dockerfile	Pins setuptools in image builds and adds --no-build-isolation to pip installs; likely fixes pkg_resources issues but introduces a requirements inconsistency (setuptools pinned here vs other files) and relies on preinstalling build deps for all sdists.
dev-requirements.txt	Pins setuptools to 80.10.2 in dev requirements to keep developer installs aligned with CI/build constraints.
docs/fides/Dockerfile	Pins setuptools/wheel and uses --no-build-isolation for fides + docs requirements install; change is large in a single RUN and may still allow newer setuptools if other requirements pull it.
noxfiles/ci_nox.py	Adjusts check_install session to preinstall pinned setuptools/wheel/versioneer and then install project with --no-build-isolation; may be sensitive to nox semantics for passing pip flags.
pyproject.toml	Pins build-system requires setuptools==80.10.2; this can break building from source on environments without that exact version available (or with incompatible Python), and is generally discouraged in PEP 517 build metadata.
requirements.txt	Adds setuptools pin and bumps scylla-driver; pin may be intentional for pkg_resources but the scylla-driver change is unrelated to stated intent and could introduce runtime/compatibility changes.

[greptile-apps]

_{9 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Unrelated dependency bump

This PR’s stated scope is pinning setuptools/disabling build isolation to address pkg_resources build breakages, but it also bumps scylla-driver (3.26.8 → 3.29.7). That introduces a behavior/compatibility change at runtime that isn’t explained or tested here, and it makes it harder to reason about whether the CI fix is safe. If the scylla bump isn’t required for the setuptools issue, it should be reverted/split into a separate PR with its own rationale/test plan.

[greptile-apps]

Overly strict build pin

Pinning build-system.requires to an exact setuptools==80.10.2 can hard-fail source builds in environments where that exact wheel isn’t available (or Python compatibility differs), because PEP-517 frontends must satisfy this requirement before any build can proceed. For the stated goal (avoid newer setuptools that dropped pkg_resources), consider using a bounded range (e.g. <82) here and keep the exact pin in CI/Docker where the environment is controlled.

[greptile-apps]

Pin may be overridden

The image pins setuptools==80.10.2 initially, but subsequent pip install ... -r requirements.txt/optional-requirements.txt/dev-requirements.txt can still cause pip to replace setuptools if any requirement set constrains it differently (or if pip decides to resolve differently). If the intent is to guarantee this version throughout the build, prefer enforcing it via a constraints file (e.g. pip install -c constraints.txt -r requirements.txt) rather than a one-off preinstall.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[greptile-apps]

Additional Comments (1)

docs/fides/Dockerfile
Setuptools pin not enforced

This installs setuptools==80.10.2 and then later runs pip install --no-build-isolation -r docs/fides/requirements.txt without --no-deps/constraints; if that requirements set (or its transitive deps) specifies a different setuptools requirement, pip may upgrade/downgrade setuptools after the initial pin, defeating the purpose. To make the pin reliable, pass it as a constraint (-c) or include it in the requirements/constraints file used for that install step.

[thabofletcher]

I dont think we should worry too much about greptiles comments, this LGTM once it passes