chore: separate deploy from polywrap project

[cbrzn]

Creates a new PolywrapDeploy class which takes care of the deploy logic. Now user does not need to have polywrap.yaml to deploy a wrapper.

TODO:

• Remove deploy attribute from extensions in polywrap.yaml

block: #1476
closes #1426

[cbrzn]

one open question: now that this pr removes the dependency of having a polywrap.yaml to do a deploy, would it make sense to remove deploy from the extensions attribute of the polywrap.yaml manifest?

[pileks]

one open question: now that this pr removes the dependency of having a polywrap.yaml to do a deploy, would it make sense to remove deploy from the extensions attribute of the polywrap.yaml manifest?

I think there's precedent for this (polywrap.test.yaml), and deploy is a very similar manifest to test, so I'm in 100% agreement with this.

[cbrzn]

one open question: now that this pr removes the dependency of having a polywrap.yaml to do a deploy, would it make sense to remove deploy from the extensions attribute of the polywrap.yaml manifest?

I think there's precedent for this (polywrap.test.yaml), and deploy is a very similar manifest to test, so I'm in 100% agreement with this.

@pileks perfect, working on this now

[pileks]

Overall this is a great change and a step forward in a direction we've already taken with build and codegen!

One thing I'd note - When migrating the templates, it would be a good excercise to migrate them using polywrap manifest migrate, so that you make sure that you are creating a migration that can truly migrate our manifests (of course, there can always be breaking changes which prevent you from this).

Apart from some nitpicks, I'd say that I'd personally go with the delete approach in the migration.

[pileks]

Looking great!

[dOrgJelli]

Hey @cbrzn @pileks, some thoughts on how I think we should treat the project manifest (polywrap.yaml) and what we currently call "extensions" manifests (build, infra, test, deploy, etc).

First thought is, I think we should remove the concept of a project "extension" and create a much simpler & uniform experience for the CLI. Instead I think we should call them command manifests, which can be defined for the various CLI commands: polywrap.build.yaml, polywrap.infra.yaml, polywrap.test.yaml, polywrap.deploy.yaml.

Second, we should have the command manifests back-link to the project they are referencing (if needed). Currently only the polywrap.build.yaml manifest needs to reference a project that is to be built. It should do this through a property within itself, for example project: ./polywrap.yaml.

Lastly, commands will have default naming conventions for their manifests (i.e. polywrap.build.yaml, polywrap.deploy.yaml, etc).

The result of doing these things is that we:

• Create a much simpler experience that can be explained easily.
• Remove the unnecessary concept of "project extensions", which doesn't apply well to all manifest types (as we see here with deploy).

Thoughts?

[dOrgJelli]

Okay, spent some time digging into this #1482 (comment) and have a bit more of an appreciation for the concept of a "project exetension". I think project extensions make sense for things like the build & codegen command, since they both require a project manifest (polywrap.yaml), and can optionally have additional configuration options set within another manifest (polywrap.build.yaml), which is the extension manifest.

So, this means that the following will be true:

• Project commands like polywrap build and polywrap codegen will require a polywrap.yaml project manifest, and will look for an optional extension manifest for added configuration options. For example: polywrap.build.yaml, polywrap.codegen.yaml.
• Stand-alone commands like polywrap infra, polywrap test, and polywrap deploy will not require a polywrap.yaml manifest be present, and will instead look for their command manifests. For example: polywrap.infra.yaml, polywrap.test.yaml, polywrap.deploy.yaml.

I know this is right back where we started, but just wanted to fully explore the options here and explain the rationale.

[dOrgJelli]

Here's the PR @cbrzn: #1486

[cbrzn]

I know this is right back where we started, but just wanted to fully explore the options here and explain the rationale.

@dOrgJelli what you said makes sense, and I also thought that we should only have build as an extension in polywrap.yaml. Thanks for explaining the thing about the version, nice catch there.

I will merge and fix the tests