grow: delegate register initialization to external projects

[Juanjo Presa]

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.

[David Arnold]

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.

[timd]

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?

[David Arnold]

This exploration might make this eventually possible: https://github.com/paisano-nix/core/tree/paisano-haumea/sprout