Dependency version pinning

[gwerbin]

I am trying to use the Optimizely SDK, but my application also requires jsonschema >= 4.0.1, because it includes support for the newer JSONSchema specification drafts. Optimizely SDK requires exactly jsonschema = 3.2.0, so I am not able to use them together.

Is it possible to un-pin the version of jsonschema and pyrsistent?

Pinning dependencies in libraries (as opposed to "applications") is very unusual, and puts a lot of restrictions on users.

Normally one would expect that a minimum version is set, of course, but not an exact pinned version!

And in this case, it also seems like the version pin isn't even necessary, since the last version bump didn't seem to require any code changes.

For example, it is effectively impossible to use Optimizely SDK and support OpenAPI Specification 3.1 in the same application. This is because OAS 3.1 specifies a JSONSchema draft that is not available in jsonschema 3.2.0. Practically, most schemas can be parsed with Draft 7, which is available in 3.2.0, so you can mostly work around the problem. But it was surprising to find this dependency conflict at all.

Is there a compelling reason to keep dependencies pinned to exact patch versions in an SDK/library? It would make this much mroe user-friendly if these constraints were relaxed.

I see that dependency versions were discussed in the past, but I didn't see any discussion of un-pinning.

[Mat001]

@gwerbin Thanks for your request.
The reason we're capping the two versions is because we're still supporting older Py versions that don't work on newer versions of jsonschema and pyrsistent.

When I tested unpinned versions of jsonschema ann pyrsistent the Py 2.7, 3.5 and PyPy2 fail in Travis CI tests, unable to find a suitable jsonschema version.

We've been debating internally removing support for some older Py versions (2, 3.5, pypy2). If we go ahead that would allow us to perform the unpinning.
I need to find out if there are and customer dependencies on those older versions and in general bring it up for discussion in the team.

Besides that I'm trying to find a version range that would allow jsonschema 4.0.1 (at least) while having older Py versions pass.

[gwerbin]

Thanks for the reply and explanation, @Mat001.

Maybe there should be a <= constraint and not a ==? At least then you aren't pinning to a precise patch version, even if it doesn't solve the particular problem I stated in my original post.

[Mat001]

Thanks for the reply and explanation, @Mat001.

Maybe there should be a <= constraint and not a ==? At least then you aren't pinning to a precise patch version, even if it doesn't solve the particular problem I stated in my original post.

Yes, that's what I tried (<=) and it breaks tests for Py 2, 3.5 and pypy.

[Mat001]

@gwerbin You may be pleased to hear that we will be releasing soon a major release with a new feature that will also include a fix for jsonschema and pyrsistent. you should be good to use your jsonschema version then. Both will be upped to the latest. We'll basically remove support for older Py versions that have been holding back the lib version upgrade.

[Mat001]

@gwerbin New SDK version released.

[Mat001]

Fixed by removing old Python versions that allowed increase in jsonschema version. Done.

[gwerbin]

Thank you so much!