Nic Cope

What if we supported dynamic function pipelines? What I'm imagining is that a function can optionally return other functions (and inputs) Crossplane should run. Perhaps these functions would run after...

> Having a standardized field referencing mechanism in core Crossplane would be incredibly helpful, allowing us to avoid reimplementing this logic in every function and instead rely on shared, well-tested...

This older issue proposes pretty much the same thing: https://github.com/crossplane/crossplane/issues/4281

The suggested approach was considered and discarded during the design that ultimately resulted in `initProvider`. I'm reluctant to move toward an approach where we end up supporting both initProvider and...

This isn't super intuitive, but looking at the upjet code, something like this might do the trick: ```yaml apiVersion: example.crossplane.io/v1 kind: SomeResource metadata: name: some-resource spec: # Specify tags in...

If I recall correctly the templating tool supports an `init.sh` file that can be run to do repo-specific initialization. Could this be done there instead? I'm a little reluctant to...

@blakeromano I think there's two issues (at least) with that. First, composition functions aren't always going to be an ideal 'trigger' for day two things. Imagine you want to make...

A manual trigger would also be interesting. So so far we have the following possible triggers: * Cron schedule * Manual * XR/MR watch (created, updated, deleted) I wonder if...

> For inputs you could have the equivalent of an XRD that defines the configuration schema of a run. I'm on the fence about how much an abstraction like this...

> The separation of concerns here depends a bit on the structure of the organization. Yeah, I definitely agree wanting a separation of concerns is likely for some folks. I...