feat: pin deps for Python 3.8 #366
Conversation
There was a problem hiding this comment.
Pull request overview
This PR regenerates and updates the dependency pins and tooling to be compatible with Python 3.8, and adds explicit constraints to keep key tooling versions within Python 3.8–compatible ranges.
Changes:
- Regenerated
requirements/base.txt,requirements/test.txt,requirements/pip.txt, andrequirements/pip_tools.txtwith Python 3.8, updating many package versions and# viametadata. - Added
boto3<1.38andpip-tools<7.0constraints to ensure compatibility with Python 3.8. - Simplified and corrected the
make upgradeworkflow and removed the olderpip-toolsrequirements files that used the hyphenated naming.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 15 comments.
Show a summary per file
| File | Description |
|---|---|
| requirements/test.txt | Regenerated test-time dependency lockfile with Python 3.8, adjusting many package pins and dependency provenance comments. |
| requirements/pip_tools.txt | Regenerated the pip-tools lockfile for Python 3.8, pinning pip-tools to a pre-7.0 version and recording its transitive deps. |
| requirements/pip.txt | Regenerated pip bootstrap requirements for Python 3.8, updating pinned pip and setuptools versions. |
| requirements/pip-tools.txt | Removed old, hyphenated pip-tools lockfile now superseded by requirements/pip_tools.txt. |
| requirements/pip-tools.in | Removed old, hyphenated pip-tools input file in favor of requirements/pip_tools.in. |
| requirements/constraints.txt | Added explicit boto3<1.38 and pip-tools<7.0 constraints with documentation tying them to Python 3.8 support. |
| requirements/base.txt | Regenerated base dependency lockfile under Python 3.8, including boto/boto3/botocore pins aligned with the new constraints. |
| Makefile | Updated upgrade target to bootstrap pip-tools, regenerate pip_tools.txt and pip.txt, and then rebuild base and test requirements with the new workflow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| botocore==1.37.38 | ||
| # via | ||
| # -r requirements/base.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via -r comment contains a developer-specific absolute path (/Users/adusenbery/...). To avoid embedding local paths in versioned requirements, please change it to a repo-relative reference such as requirements/base.txt.
| # via pyresttest | ||
| google-compute-engine==2.8.13 | ||
| # via -r requirements/base.txt | ||
| # via -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via -r origin comment uses an absolute path (/Users/adusenbery/.../requirements/base.txt), which bakes a local filesystem layout into the requirements file. Please switch this back to a relative reference like requirements/base.txt so the file works across environments.
| markupsafe==2.1.5 | ||
| # via | ||
| # -r requirements/base.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This origin comment references /Users/adusenbery/.../requirements/base.txt, which will not exist for other developers or CI. It should instead use a repository-relative path (for example, requirements/base.txt) to keep the requirements file portable.
| six==1.17.0 | ||
| # via | ||
| # -r requirements/base.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via entry references requirements/base.txt via an absolute path under /Users/.... To avoid hard-coding local filesystem structure into versioned files, please change this to a repository-relative path (e.g., requirements/base.txt).
| urllib3==1.26.20 | ||
| # via | ||
| # -r requirements/base.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via comment uses an absolute filesystem path (/Users/adusenbery/.../requirements/base.txt), which is specific to one developer's environment. It should instead reference requirements/base.txt (or the appropriate relative path) to keep the file portable and reproducible.
| python-dateutil==2.9.0.post0 | ||
| # via | ||
| # -r requirements/base.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via comment contains a hard-coded absolute path to requirements/base.txt in a local workspace. Please replace it with a relative path such as requirements/base.txt so the generated requirements do not depend on any specific user directory layout.
| s3transfer==0.11.5 | ||
| # via | ||
| # -r requirements/base.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via line embeds an absolute path (/Users/adusenbery/.../requirements/base.txt), which makes the requirements file non-portable. It should be updated to use a repo-relative reference to requirements/base.txt instead.
| botocore==1.42.31 | ||
| boto3==1.37.38 | ||
| # via | ||
| # -c /Users/adusenbery/code/api-manager/requirements/constraints.txt |
There was a problem hiding this comment.
This comment line embeds a developer-specific absolute path (/Users/adusenbery/...) into the generated requirements file. These # via -c references should use repository-relative paths (for example, requirements/constraints.txt) to keep the file portable across machines and CI environments, and consistent with other # via entries in this repo.
| # -c /Users/adusenbery/code/api-manager/requirements/constraints.txt | |
| # -c requirements/constraints.txt |
| # via | ||
| # -r requirements/base.txt | ||
| # -c /Users/adusenbery/code/api-manager/requirements/constraints.txt | ||
| # -r /Users/adusenbery/code/api-manager/requirements/base.txt |
There was a problem hiding this comment.
This # via -r origin comment includes a hard-coded absolute path to a local checkout. For portability and consistency with other # via lines, this should reference requirements/base.txt (or the appropriate repo-relative path) instead of /Users/....
| upgrade: ## update the requirements/*.txt files with the latest packages satisfying requirements/*.in | ||
| pip install -q -r requirements/pip_tools.txt | ||
| pip-compile --upgrade --allow-unsafe --rebuild -o requirements/pip.txt requirements/pip.in | ||
| python -m pip install pip-tools |
There was a problem hiding this comment.
The upgrade target installs pip-tools directly from PyPI with python -m pip install pip-tools, which pulls an unpinned third-party build tool and executes its code each time make upgrade runs. If an attacker compromises the pip-tools package or your package index, this step can lead to remote code execution during dependency compilation and allow malicious versions of downstream dependencies to be pinned into your requirements. Install pip-tools only from a pinned version (for example via your requirements/pip_tools.txt and constraints) so that builds always use a vetted, immutable tool version.
|
closed in favor of: #367 |
https://2u-internal.atlassian.net/browse/ENT-11416