grow: delegate register initialization to external projects
oneingan opened this issue · comments
I've been using the grow
function in the paisano
project and I've noticed that it initializes the ci
register internally. However, I think that it would be more flexible and beneficial to delegate the initialization of registers to external projects.
Specifically, I suggest having the std
project initialize the ci
register, while other projects initialize different registers that they may need. This would allow users to customize the initialization process for different registers to suit their specific needs.
By delegating the register initialization to external projects, it would make the grow function more powerful and useful for a wider range of use cases.
I would love to hear your thoughts on this suggestion, and if there are any specific concerns you may have.
I think that's a good and principled idea.
Now, as for CI, this is likekely to be universally useful in a majority of cases, also in combination with things like std-action
which turns out to be a misnomer and could be currently called paisano-action
, if pushing paisano is what we wanted [currently not].
Now, on the other hand, I can start to see cases where downstream adopters might want to instantiate their own registry.
So it is indeed useful to factorize that logic somehow, maybe via a callback that "rides" along the 3 nested layers of collector logic.
But once we're there, we can likely break this up further, maybe even the ci itself as you suggest.
Not a bad idea in principle, but I do wonder what the harm is, since Nix is lazy anyway? Are you wanting to use a custom ci
register with a different schema perhaps?
This exploration might make this eventually possible: https://github.com/paisano-nix/core/tree/paisano-haumea/sprout