Our sloppy container spec bit us today though. We had
FROM: python:3-slim
with a bunch of pip requirements following. Some of those were not 3.11 ready, eg scipy==1.8.0, and our build broke. Our answer was to not be sloppy and pin until everything catches up, eg
FROM: python:3.10.8-slim
and we're good. Hope someone sees this that needs reminding.
Good question and thank you for raising that possibility. I am ignorant here. Of course I'd prefer patches applied asap but...
We are almost daily discovering upstream changes like this one that breaks something N components removed so our kneejerk response is usually to pin aggressively when found and periodically upgrade deps for a whole component.
What are the chances I have some dep somewhere that says python<=3.10.8 and is working today but when that 3.10-slim spec allows 3.10.8 turn into 3.10.9 it will break? That's what happened today for scipy but on the 2nd int and not the third one, because we had started with 3-slim.
A related note is for any requirements files. Something like this bit me the other day.
Libraryname >=3.1
After a few years,the package was updated substantially and has lots of breaking changes in the recent branch. Fix was to so ==3.1 until we work out the next step
I was bitten once a few years ago and have always pinned everything since then.
And of course last year I was bitten by a ~ in a package.json that I hadn't got around to pinning in a code base I'd inherited.
Our sloppy container spec bit us today though. We had
with a bunch of pip requirements following. Some of those were not 3.11 ready, eg scipy==1.8.0, and our build broke. Our answer was to not be sloppy and pin until everything catches up, eg and we're good. Hope someone sees this that needs reminding.