aicam commented on PR #6911:
URL: https://github.com/apache/texera/pull/6911#issuecomment-5095922752
Closing this one — the bump can't land while `fs` is still in the dependency
set, and the green CI here is misleading.
**Why it can't merge:** setuptools 82.0.0 removed `pkg_resources`, and
`fs==2.4.16` imports it at module-import time (`fs/__init__.py` line 4,
`__import__("pkg_resources").declare_namespace(__name__)`).
`core/architecture/managers/executor_manager.py` imports `fs` unconditionally,
so this takes out the Python worker at startup. In a clean venv:
```
$ pip install setuptools==83.0.0 fs==2.4.16
$ python -c "import fs"
ModuleNotFoundError: No module named 'pkg_resources'
```
**Why CI is green anyway:** the pyamber job installs
`amber/requirements.txt` and `amber/operator-requirements.txt` in two separate
resolver passes, and `torch==2.12.1` declares `setuptools<82`, so the second
pass silently undid the bump before pytest ran. From the `build / pyamber
(ubuntu-latest, 3.13)` log on this PR:
```
+ setuptools==83.0.0
- setuptools==83.0.0
+ setuptools==81.0.0
```
The tests ran on 81, not 83 (the log also carries the `pkg_resources is
deprecated` warnings from `fs/__init__.py`). A single-pass install of both
files with `==83.0.0` is unresolvable against torch's `<82`.
**Answering @aicam's question** — which library needs it: `fs` is the only
one. Checking the `requires_dist` of every pinned package in
`amber/requirements.txt`, `fs==2.4.16` is the sole distribution declaring
`setuptools` (psutil declares it only under its `dev`/`test` extras, which we
don't install). So it can't be dropped in favour of "whatever version the other
library wants" — the version `fs` wants is exactly the vulnerable one, and `fs`
has been unmaintained since May 2022 with no successor release.
**On the advisory itself:** CVE-2026-59890 is a `MANIFEST.in` exclusion
bypass when *building an sdist* on macOS APFS/HFS+. Nothing in amber builds an
sdist — `amber/pyproject.toml` carries only ruff and pytest config, there is no
`build-system` or `setup.py`. setuptools is present purely as a runtime shim so
`import fs` works. Practical exposure is nil, so there's no urgency forcing a
bad merge here.
**The way forward** is #6917 (drop `fs` for `tempfile.mkdtemp` +
`shutil.rmtree` in `ExecutorManager`), as @aglinxinyuan noted above. Removing
`fs` lets the `setuptools` line be deleted outright, which is the only change
that actually clears this advisory. If that doesn't land soon, #6412
(`setuptools<82`) is the stopgap — it encodes the real constraint so a future
bot bump past the removal can't land silently, though it won't silence the
alert since 81 is still flagged.
Separately worth fixing: installing the requirement files in one resolver
pass (or passing `operator-requirements.txt` as a constraint file) would have
made this conflict fail loudly instead of being silently downgraded.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
