Use workflows in meta manifest to compile examples of all the methods

[Niraj-Kamdar]

[dOrgJelli]

Hey @Niraj-Kamdar, could you provide additional details as to what the implementation of this should look like?

A few questions:

• How does this relate to deploying workflows as stand-alone projects?
• What is the URI being used in the workflow?
• How can the workflow reference the wrapper it is bundled with?

[Niraj-Kamdar]

@dOrgJelli I am not sure whether we want to do it this way now. Before we had recipe embedded in the meta manifest that's why when we upgraded to workflow I thought we would want similar but after that, I came to the conclusion that workflow is much more powerful than just a way to provide sample queries.

There are 3 main usecases of the workflows in the context of wrapper:

1. e2e testing of a wrapper with workflow
2. Provide invocation example for a wrapper with workflow
3. Create a composable workflow wrapper

For 1 and 2, we need to embed the workflow with the wrapper project and distribute it as a part of project. It can be in meta but I don't think it's the right place to keep this instead it should be as its own manifest - maybe polywrap.test.yaml and will be embedded inside the build artifact for wrapper.

3 is the most awesome usecase for the workflow though, it's a way to write a wrapper without coding by composing different wrappers. this can be useful to a lots of web3 project including our partners collab-land and gelato.

I believe that a suite of workflows can be compiled as a wrapper just like plugins and wasm wrappers, we will have workflow wrappers. We will have a similar kind of schema, abi, etc that we have for wasm and plugin wrapper but implementations will be in yaml/json as a suite of composable wrappers. This kind of workflow wrapper project will have its own project and will be described in workflow manifest just like we have wasm and plugin manifest.

[dOrgJelli]

Awesome I like how you broke down the 3 use-cases, and I agree. We can introduce the polywrap.test.yaml manifest in the future, as this will come in handy when performing continuous integrations for new wrapper versions that get published (recall our previous version registry conversations that have been shelved).

I agree that the next step here is to work on number (3), where we are able to publish workflows as their own stand-alone package. Want to create an issue for that and close this one?