all_flags_state while using the TestData data source.application config property which sets application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.application config property which sets application metadata that may be used in LaunchDarkly analytics or other product features. . This does not affect feature flag evaluations.The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."
This feature is only available to members of LaunchDarkly's Early Access Program (EAP). If you're in the EAP, you can use contexts by updating your SDK to the latest version and, if applicable, updating your Relay Proxy. Outdated SDK versions do not support contexts, and will cause unpredictable flag evaluation behavior.
If you are not in the EAP, only use single contexts of kind "user", or continue to use the user type if available. If you try to create contexts, the context will be sent to LaunchDarkly, but any data not related to the user object will be ignored.
For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide.
ldclient, the Context type defines the new context model.dict, you can now pass a Context instead. You can still pass a dict containing user properties, in which case the SDK will convert it to a Context transparently; however, Context is preferable if you value efficiency since there is some overhead to this conversion.TestData flag builder methods have been extended to support now context-related options, such as matching a key for a specific context type other than "user".secondary meta-attribute that affects percentage rollouts. If you set an attribute with that name in a Context, it will simply be a custom attribute like any other.anonymous attribute is now a simple boolean, with no distinction between a false state and a null/undefined state. Previously, a flag rule like anonymous is false would not match if the attribute was undefined, but now undefined is treated the same as false.ldclient.flag module. This was previously an alternate way to import the EvaluationDetail type; now, you can only import that type from ldclient.evaluation.alias method no longer exists because alias events are not needed in the new context model.inline_users_in_events option no longer exists because it is not relevant in the new context model.redis_opts parameter is available when configuring a Redis feature or Big Segment store. This parameter will be passed through to the underlying redis driver, allowing for greater configurability. (Thanks, danie1k!)TestData, in the new module ldclient.integrations.test_data, is a new way to inject feature flag data programmatically into the SDK for testing—either with fixed values for each flag, or with targets and/or rules that can return different values for different users. Unlike the file data source, this mechanism does not use any external resources, only the data that your test code has provided.threading.Condition.notifyAll(). (Thanks, jdmoldenhauer!)None.secondary attribute will now reference the correct value.identify method should not emit an event if the user key is an empty string.prereqOf field in event data if it is null. This is done to save on event transfer bandwidth.all_flags_state was always including the flag's version even when it was unnecessary.Config will work consistently whether they have trailing slashes or not.all_flags_state to produce bootstrap data for the JavaScript SDK, the Python SDK was not returning the correct metadata for evaluations that involved an experiment. As a result, the analytics events produced by the JavaScript SDK did not correctly reflect experimentation results.all_flags_state was always including the flag's version even when it was unnecessary.alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.uwsgi module is present in an incomplete state; this could cause an error on startup in such environments. Also, the log message about threading options related to uWSGI contained a broken link. (Thanks, andrefreitas!)This major release is for Python compatibility updates and removal of deprecated APIs. It introduces no new functionality except type hints.
Config constructor, sdk_key, is now required. Previously it was possible to omit the sdk_key from the Config and specify it separately when initializing the SDK. Now, it is always in the Config.ldclient.set_sdk_key(). The correct way to do this now, if you are using the singleton client method ldclient.get(), is to call ldclient.set_config() with a Config object that contains the SDK key.LDClient constructor. You must now provide a configuration parameter of type Config, and set the SDK key within the Config constructor: LDClient(Config(sdk_key = "my-sdk-key", [any other config options])). Previously, it was possible to specify the SDK key as a single string parameter and omit the Config object—LDClient("my-sdk-key")—although this would cause a deprecation warning to be logged; specifying both a key and a Config was always an error.connect_timeout from the Config type. The correct way to set these now is with the HTTPConfig sub-configuration object: Config(sdk_key = "my-sdk-key", http = HTTPConfig(connect_timeout = 10)).http://username:password@proxyhost:port). It will now use these parameters if present, regardless of whether you set the proxy URL programmatically or in an environment variable. (Thanks, gangeli!)urllib3.Retry could prevent analytics event delivery from being retried after a network error or server error. (#143)