re-introduce the docling fix; fix DISABLE_GPU_ACCELERATION setting via GITHUB_ENV file (backport #3271) - #3277

@courtneypacheco @ktdreyer should we really backport a patch that changes dependencies (here we add/bump docling)? Should we instead cap docling instead? (or contrive a way to work with both versions?)

I think we really want users to have the latest docling.

@dhellmann are you ok with backporting patches to release branches that include bumps for dependencies like docling? Please advise, I don't see a policy on this matter in dev-docs, but it seems wrong, as per my experience in other projects.

@dhellmann are you ok with backporting patches to release branches that include bumps for dependencies like docling? Please advise, I don't see a policy on this matter in dev-docs, but it seems wrong, as per my experience in other projects.

What we usually did in OpenStack was to leave the minimum bound in place unless the newer version of the library had backwards-incompatible changes that required code changes in the consuming code. We did that because it allowed vendors distributing the project downstream some latitude about picking up changes in the z-stream releases. If they wanted some fixes, but not others, they would still get a compatible set of packages. It is safe to leave the lower bounds alone because the installer tools default to selecting the newest available package that match the rules.

@dhellmann, sadly, it's the case of backward incompatible changes in docling.

The new docling broke instructlab. So we know that new docling versions don't work - without the patch included here. But: the patch being backported also breaks instructlab if older docling is used (hence the minimal version bump).

In this case, what's preferred: to cap docling and leave instructlab code intact? Or to bump docling, forcing existing users of a release branch to upgrade dependencies?

(A third option would be to make instructlab gracefully handle both versions, but it would require type inspection to detect which docling interface is present; there's no patch to do that. But theoretically, it's possible to write one.)

@dhellmann, sadly, it's the case of backward incompatible changes in docling.

The new docling broke instructlab. So we know that new docling versions don't work - without the patch included here. But: the patch being backported also breaks instructlab if older docling is used (hence the minimal version bump).

In this case, what's preferred: to cap docling and leave instructlab code intact? Or to bump docling, forcing existing users of a release branch to upgrade dependencies?

In order to deliver the fix downstream in the product we need the newer docling and the code changes that go with it. So while it's not ideal, it seems like the necessary solution.

(A third option would be to make instructlab gracefully handle both versions, but it would require type inspection to detect which docling interface is present; there's no patch to do that. But theoretically, it's possible to write one.)

That would be another option, but I'm not sure it's worth the effort. I don't know how many people upstream are using the branch, and we know we need the new code downstream.