aminghadersohi opened a new pull request, #43521:
URL: https://github.com/apache/superset/pull/43521
## Why
#43417 (`chore(deps): bump marshmallow from 4.3.0 to 4.3.1`) did not only
bump the pinned version in `requirements/base.txt` — it also raised the
*declared lower bound* in `pyproject.toml`:
```diff
- "marshmallow>=3.0, <5",
+ "marshmallow>=4.3.1, <5",
```
That looks like an unintended side effect of the automated bump rather than
a deliberate policy change:
- The previous state already resolved `marshmallow==4.3.1` in the lockfile
while the declared floor deliberately stayed at `>=3.0`. Raising a floor to
match a lock pin removes the distinction between "what we test against" and
"what we support".
- The line immediately above the constraint points at
`superset/marshmallow_compatibility.py`, i.e. the codebase carries an explicit
marshmallow 3/4 compatibility shim. A hard `>=4.3.1` floor makes that shim
unreachable for its marshmallow 3 half.
- Several packages still in wide use cap marshmallow below 4 — most notably
`dataclasses-json` (`marshmallow>=3.18.0,<4.0.0` as of its latest release,
0.6.7), which is pulled in by `langchain-community<0.4.2`. Any downstream that
installs Superset alongside such a package now gets an unsatisfiable resolution
rather than a working marshmallow 3 install.
This is a real, reproducible break for downstream distributions that embed
Superset as a library. Resolving `apache-superset` together with
`marshmallow==3.26.2`:
```
× No solution found when resolving dependencies:
╰─▶ Because only apache-superset==0.0.0.dev0 is available and
apache-superset==0.0.0.dev0 depends on marshmallow>=4.3.1,<5, we can
conclude that all versions of apache-superset depend on
marshmallow>=4.3.1,<5.
And because you require marshmallow==3.26.2 and apache-superset, we can
conclude that your requirements are unsatisfiable.
```
## What
Restore the declared lower bound to `marshmallow>=3.0, <5`. One line in
`pyproject.toml`.
The pinned version in `requirements/base.txt` is left at `4.3.1`, so CI, the
Docker images, and every developer install continue to test against marshmallow
4.3.1 exactly as they do today. Only the *supported* range widens back to what
it was before #43417.
## Blast radius
None for this repository's own testing or runtime: the resolved version is
unchanged (`requirements/base.txt` still pins `marshmallow==4.3.1`). The change
affects only what a downstream resolver is permitted to select.
## How to test
```bash
# Before: unsatisfiable
uv pip compile - <<< $'marshmallow==3.26.2\n-e .'
# After: resolves
uv pip compile - <<< $'marshmallow==3.26.2\n-e .'
```
`pip install -r requirements/base.txt` is byte-for-byte unchanged, as the
lock pin is untouched.
## Risk & rollback
Low. Reverting is a one-line change back to `>=4.3.1`. There is no migration
and no runtime behaviour change.
The one thing worth deciding explicitly: if the project *does* want to drop
marshmallow 3 support, that should be a deliberate change that also removes
`superset/marshmallow_compatibility.py`'s marshmallow 3 branch and is called
out in `UPDATING.md` — not a side effect of a dependabot patch bump. If that is
in fact the intent, please close this PR and I will adjust downstream instead.
## Review guidance
Single-line diff. The question to answer is just: was the floor raise in
#43417 intentional, or incidental to the lock bump?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
