Closed todofixthis closed 10 months ago
Need to think about how to deprecate the existing AutoRegister
gracefully.
Maybe keep the existing AutoRegister
but add a DeprecationWarning
when it's called. Then add a new AutoRegister
to class_registry.base
maybe?
After a few releases I can then remove the old AutoRegister
, or maybe just keep it but rename to AutoRegisterMeta
? This would be a good use case for adding telemetry, but that's against my religion, so.... ๐
Maybe do a quick survey of public projects that use phx-class-registry
in GitHub, GitLab, Bitbucket and see if anyone is using AutoRegister
๐ค
I'm not sure if I'm hoping that people are using it, or that people aren't using it ๐น
Thanks to https://peps.python.org/pep-0487/ we now have
__init_subclass__
which can (amongst other things) be used to automatically add classes to a registry. As a result,AutoRegister
no longer needs to return a metaclass, which would substantially improve its interoperability with other libraries (e.g., Pydantic).I think something more-or-less like this should work nicely:
Also, I think
AutoRegister
can drop itsbase_type
parameter, as developers could achieve the same outcome with multiple inheritance, e.g.:An alternative would be to make
registry
a kwarg for__init_subclass__
, so thatAutoRegister
becomes an actual class instead of a function that returns same...but that feels brittle to me, as it could potentially cause conflicts if another base class is expecting a kwarg with the same name.But then, I've never been comfortable with this style, so maybe I'm the problem ๐