🏗️ Settings: From pydantic BaseModel to custom class

[falexwolf]

pydantic isn't so great in our case:

• As during setup, settings are written iteratively and need functionality from previous settings, there is no simple point in time where we can instantiate and validate all settings using pydantic BaseModel.
• BaseModel does not support editable docstrings on the attribute level, which makes it hard to share documentation. (Edit: It turns out that it's also not so easy with ordinary classes, I thought I had it work before. 🤷‍♂️)
• BaseModel does not recognize CloudPath and can't validate it, which is why we had to introduce storage_root_str, defeating almost the whole point of a typed Settings class.

Using a custom dataclass, now we migrated to pickle instead of writing a JSON. Let's see whether we regret it. Pro is that it supports CloudPath and Path, which JSON doesn't. Con is that it's not human-readable and I might not see a way in which it might break.

A big change is also that we are now using setup.settings() instead of setup.settings. The latter always resulted in some quirks in some form. For instance, no auto-complete when using the "module attribute" hack (__getattr__("settings")). It seems cleaner to have a callable who will always read the current state of settings.

An alternative is to require shut down of the kernel after setup has been run, but that seems bad for the UX at least in the current state.

[github-actions]

🚀 Deployed on https://62b723266d2aa1082c0cb428--lamindb-90f32c8dml.netlify.app