search

optimizely / python-sdk

Python SDK for Optimizely Feature Experimentation and Optimizely Full Stack (legacy)
https://docs.developers.optimizely.com/experimentation/v4.0.0-full-stack/docs/python-sdk
Apache License 2.0
32 stars 36 forks source link

Dependency version pinning #370

Closed gwerbin closed 2 years ago

gwerbin commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@gwerbin New SDK version released.

Mat001 commented 2 years ago

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

gwerbin commented 2 years ago

Thank you so much!