open-feature
0.7.0 breaking changes - compatibility tracking issue
With 0.7.0, we are taking a more strict approach to exporting names in our public API. In https://github.com/open-feature/python-sdk/pull/306 we began using __all__ inside each package to explicitly declare the names that are exported from it, thus enforcing a canonical import path for each class/function.
Package maintainers: if you were previously importing names from non-canonical locations, you will need to update your imports to point to the canonical ones. Your code should then be able to work with both current and 0.7.0 SDK versions.
We will be releasing 0.7.0 next week probably, and we will be following it up with a 1.0 shortly after 🎉
If you have any other questions, feel free to leave a comment here.
Packages that may need updating
- [ ] https://pypi.org/project/cloudbees-openfeature-provider-python/
- [ ] https://pypi.org/project/split-openfeature/
- [ ] https://pypi.org/project/confidence-openfeature-provider/
- [ ] https://pypi.org/project/launchdarkly-openfeature-server/
- [ ] https://pypi.org/project/openfeature-provider-flagsmith/
- [x] https://pypi.org/project/gofeatureflag-python-provider/
- [ ] https://github.com/DevCycleHQ/python-server-sdk
tagging @AsafRollout @rgrassian-split @nicklasl @keelerm84 @matthewelwell @thomaspoignant @chris-hoefgen
@federicobond thanks for the heads up, do you have any example of what tondo by any chance?
If you are doing things like:
from openfeature.api import EvaluationContext
You will have to change it to point to the canonical location:
from openfeature.evaluation_context import EvaluationContext
Easiest way to check support is running pip install git+https://github.com/open-feature/python-sdk.git@main before your provider test suite.
It should be ok for GO Feature Flag, waiting for the SDK to be released to release the new version of the provider.