I can see the problem that providing all the information can be tedious at first, but I also think that hiding the live resource configuration behind another module is not perfect either. Especially when it comes to supporting multiple data sources, like Ecto or Ash.
The setup is not that easy anyway, and creating another abstraction (live resources are already an abstraction for resources) makes it even more complicated.
I really appreciate your work and ideas to simplify the setup, but I guess we will not add such an auto live resources to the core at the moment. We are open to an add-on package if you need this feature and want to maintain such an automatic resource generation.
When it comes to making setup easier, I’d like to see Mix tasks that do the resource introspection and automatically generate live resources for you. The advantage of a Mix task is that we’d simplify the setup, but end up with the same configuration (both manually and programmatically via running a mix task).
I understand. I have no interest in Ash, so I just want the simplest setup possible for Ecto schemas, which is what I actually use.
I aggree, but the disadvantage is that you have to do it all over again if you edit your schema. Again, that is a tradeoff and I certainly understand your position.
Writing a mix task to do what you want is actually not too hard. You could use the debug output from my AutoLiveResource module and replace some parts with the appropriate variables in an EEx template.
The code is neatly encapsulated in a single module, which means I can publish such package myself completely independently of Backpex. The only question is whether I should do it in a different top-level namespace (e.g. BackpeXtra) or whether it would be safe to do it under something like Backpex.Extra. I guess the first option is safer, and additionally, the second option could be seen as anedorsement by Backpex, which is not the intended idea.
