Webargs 7.0 breaks usage of unknown = EXCLUDE

Per the webargs changelog

Parser.use_args , now requires you to set unknown=None be passed or Parser.DEFAULT_UNKNOWN_BY_LOCATION set if you your schema model parameter is to be respected it seems.

The result of this is that all our Schemas are defaulting to unknown=raise which broke things. Workaround for this is to set a requirement of webargs<7.0.0

[lafrech]

I just released 0.25.1 and 0.26.0 to address this.

Thanks @shughes-uk and @bryevdv for expressing your concerns.

Thanks @sirosen for sharing your wisdom.

[sirosen]

I think it would be good for flask-smorest to put upper bounds on the versions of its dependencies. It’s more important if 1.0 is released and the classifier is switched from “Beta” to “Production” – then a stronger guarantee of compatibility will be offered.

There’s not much harm in releasing new major versions of flask-smorest every time a major version of one of its dependencies ships. It’s slightly more work for us (yes, “us”: I’m willing to help out 😉 ), but IMO it’s worth it.

But even without going to 1.0, I think it’s a better experience for users if pip install 'flask-smorest==x.y.z' always grabs the same major versions of the dependencies.

There are frequent major version in those libs but for most of them the breaking change is marginal.

FWIW, I don’t want to do another major version of webargs for a long while. I considered 7.0 necessary because of the usages like dict-schemas on location="headers". I’ll advocate for working up 8.0.0 if we find that 7.x is really problematic for some users and we can’t come up with a backwards-compatible way of handling it, but it may be worth noting that I’d like to slow down the pace of major releases a bit.

I don’t think its fair to require the user to read and understand change logs for dependencies of dependencies.

I agree with this. The docs and readme don’t give users reason to expect that second-order dependencies could change in breaking ways, and change the behavior of this library.

If we’re looking at flask for an example, I think it’s also worth noting that their 0.12.x line has to pin werkzeug: https://github.com/pallets/flask/blob/79c71f24e4cb064852e2cbbfef78a0a051eb7ced/setup.py#L74

By leaving their versions open, I think the pallets team is making it possible to release a werkzeug 2.0 which is compatible with flask 1.x but makes other breaking changes. I’m not sure that I want to follow their lead on this though. They’re committed much more strongly to not making backwards-incompatible changes: even marshmallow moves much faster than flask.

If we want to avoid restricting dependency versions (per above I think upper bounds would be good, but I’m also not a maintainer of this lib), I think the docs need to call that out. If the docs say “you need to pin your webargs version”, then the situation becomes very different.

Even then if you use those environment managers [poetry, pip-tools, etc], adding flask-smorest today would result webargs 7 being installed so you’re starting out in a broken state.

This is not a fair assessment. The lockfile systems guarantee that “what worked today works tomorrow”. flask-smorest is compatible with webargs>=7,<8, so the tools should allow it. The point in time at which you introduce these things into a workflow matters – poetry and its ilk only protect you from second- and third-order dependencies changing if you introduce them at time when your application works with the specified package versions.

when a bug like this occurs

I don’t believe that there is a bug. The change in behavior in webargs – which does not respect Meta.unknown unless explicitly instructed to do so – is intentional and, from what @lafrech has said, flask-smorest works fine with this version of webargs.

Aside: although unstated, I’m well aware that the change in webargs requires annoying fiddling for the OP and similar usages. My own use of the library is the same. But the unknown behaviors were the best we could work out to handle other use-cases gracefully.

Is there any kind of workaround for this beyond locking a dependency?

Today, right now, this minute? No. I would recommend you add webargs<7, apispec<5, and marshmallow<4 to any requirements where you only have flask-smorest today. If we change how things are done in flask-smorest, possibly something different will become possible.

If I were to issue a webargs 7 compatible version, it would be just the same. I could release a new version pinning webargs < 7, then issue a major flask-smorest with the exact same code and webargs 7 documenting a breaking change about webargs being modified. But that sounds kinda weird.

Agreed, with the state we’re in right now, it seems pretty weird. But it’s also pretty easy.

I think I’d do this if it were up to me in versions 0.26.0 and 0.27.0 . That solves things for the OP (just use ==0.26.0) and gets things running smoothly again.