chore: swap core for yggdrasil

[sighphyre]

Swaps the core of the SDK for the Python bindings to Yggdrasil.

Currently this "works on my machine" because the engine isn't yet published, but all tests do pass with a local link.

Details

• Feature and variant evaluations are all handled through Yggdrasil now
• Metrics counting and retrieval is handled through Yggdrasil now
• The feature loader has been pared down to a much simpler set of functionally, all state diffing is handled by the Rust layer of the engine (currently no diffing but its coming)
• Custom strategies are handled through the Python layer of Yggdrasil now. This means an interface change for custom strategies
• All hydration paths (bootstrap, load from cache, API hit) now return strings; parsing is handled by the Rust layer of Yggdrasil
• Access to the features field has been left intact on the UnleashClient class but will now always return empty. This is intended to be swapped out for feature_definitions. features will be removed in a further clean up PR prior to release

Discussion points

• The Yggdrasil engine is a bit more fussy about types, specifically on Variants. Yggdrasil returns a dataclass, rather than the untyped dict of the SDK. I've chosen to map this to the legacy format to allow consumers an easier time moving, while giving us an option to move to something a little more concrete at a later point
• Custom strategies is a big change. This is going to require a major version and the new methods in Yggdrasil will error at initialisation time rather than warn at runtime. I think this is okay but I'm open to discussion here
• The engine isn't hinted to be private (and it's not name mangled because that's horrible) because none of the other SDK fields are. I don't believe people should be rooting around with the engine directly but Python also tends to treat its users like responsible adults so I think that's maybe okay
• I've chosen not to handle some of the YddrasilExceptions that can bubble from the engine, specifically for cases where this would be undefined behavior in the Rust layer. These Should Never Happen™ but if they do, it's not really safe for any healthy program to continue what its doing

[nunogois]

Just curious: Why do we need this?

[sighphyre]

It's a good question. Yggdrasil core returns a dataclass here (which is like an object without methods, similar to a Rust struct). I'm a fan of dataclasses because they're quite explicit about their intent. The SDK at the moment returns an untyped dict. So I don't want to change it for 3 reasons:

• Yggdrasil abstractions should stay in Yggdrasil, bleeding internal classes outside of the domain boundary is poor encapsulation
• This is one less thing for consumers to have to think about or worry about, that one is quite important to me in Python because its quite hard to know all the places you may be using a return type. This means no one has to hunt down all their variants and change the way they access data on them
• Dataclasses do optionals, which become nulls. The client spec suggests that variants without payloads shouldn't include that field rather than including a null. The dict comprehension here is filtering out nulls

[nunogois]

Would probably be cleaner to move this part over to _resolve_variant and make it always return a variant instead of either a variant or None?

[sighphyre]

I left it alone because I was going to implement the fallback function, which needs to know if there's a variant or not... then I realised we never got around to implementing that. So I'm leaving this until we do actually implement it

[nunogois]

Other than a few nitpicks it seems to me like you're doing all the right things 👍

[ivanklee86]

Some random thoughts:

• Should update the development docs on what yggdrasil is/how to upgrade.
• Custom strategy changes probably need updates.

[sighphyre]

Some random thoughts:

* Should update the development docs on what yggdrasil is/how to upgrade.

* Custom strategy changes probably need updates.

Cheers, both are absolutely on my list of things to do. I just wanted to keep this PR as narrow as possible. Will definitely be a thing prior to an actual release

[coveralls]

coverage: 95.923% (-0.6%) from 96.545%
when pulling c657db3 on chore/swap-core-for-yggdrasil
into fd59b80 on main.