Allow sylvia crates to use cw-orchestrator as well

[ethanfrey]

Sylvia is a powerful tool to make writing and composing contracts faster and safer, and also includes some great test helpers for multi-test based testing.

cw-orchestrator is a powerful tool to allow rust based testing and deployment. It starts where Sylvia stops (they both cover multitest), and then allows running real tests on local-net or osmosis test tube, as well as deploying to testnet or mainnet... all with the same, well-typed, Rust code.

As I architect the progress of mesh security, I would love to have the ability to sue cw-orch as well in this Sylvia codebase. Unfortunatley, this is currently impossible as cw-orchestrator requires a few derive macros on the ExecuteMsg and QueryMsg, which are auto-generated by sylvia and thus inaccessible.

Furthermore, I note that as of 0.22, cw-orch is on CosmWasm 1.x, so any integration should target the 0.10.x (or 0.11.x?) line of Sylvia.

Pinging @jawoznia and @hashedone for visibility on the Confio side

Pinging @Kayanski and @adairrr for visibility on the Abstarct side.

I note this is my idea and I have gotten some support from both teams to move it forward, but I am the requestor

[adairrr]

Confirming visibility! This would be a great addition to the CosmWasmers' toolkit, as it also unifies the testing suites between traditional CosmWasm contracts and Sylvia-based contracts.

[hashedone]

I've looked at the PR, and I don't like the idea of bounding the dependencies of Sylvia and cw-orchestrator. So many things can go wrong on this level that I believe it only looks simple. You just mentioned that we would need to target the Sylvia 0.10.0 line with that (that is not meant to have more features; it is only for bugfix backporting), but in fact, examples in Orchestrator still use cw 1.4, while Sylvia 0.10.0 targets 1.5. I have no idea if that would or would not cause issues. And this would have to be reensured on every sylvia release, orch release, and cw release - I find this unmaintainable.
Instead, we prefer to go more generic with the simpler design that simply forwards attributes to generated entities: #379. I mentioned it when we discussed before. This solution is both simpler and better at firing the Sylvia plans.
Also, after thinking of this I am really not a fan of adding this feature to 0.x line, and there are two reasons three reasons for that:

• It adds maintenance complexity - there are more features in the soon-to-be-deprecated version of a crate
• The 0.x branch is meant for backporting, not new features. The idea is to not encourage chains to stay on CW 1.0.0, but the opposite.
• Related to previous - why is Orchestrator not willing to support 2.0.0? There are no massive API changes there, and we would prefer to have more tooling on 2.0.0, including orchestrator.

The #379 would for sure be added to the Sylvia timeline, coming in 1.2.0. Backporting this feature to 0.10.0 (in fact 0.11) might happen, but I'd prefer avoiding it.

[ethanfrey]

Speaking for myself (not abstract, who I don't work for), I like the approach in #379

why is Orchestrator not willing to support 2.0.0? There are no massive API changes there, and we would prefer to have more tooling on 2.0.0, including orchestrator.

I think the onus is on Confio to coordinate some upgrade. If 95% of projects are on 1.x, then the tools will continue to target 1.x. If 95% of the tools are on 1.x, the projects will stay on 1.x. It needs a relatively coordinated push where the major tools and major projects (like DAO DAO, Osmosis, Kujira, Neutron) all upgrade over a number of months.

This won't happen on it's own. For example, it took years for yarn 2 to get adoption. AwesomWasm may be a good opportunity for Confio Dev Rel to get a number of projects to commit to the upgrade, so that the rest will follow.

[CyberHoward]

Speaking for myself (not abstract, who I don't work for), I like the approach in #379

I like this approach as well.

[hashedone]

I think the onus is on Confio to coordinate some upgrade. If 95% of projects are on 1.x, then the tools will continue to target 1.x. If 95% of the tools are on 1.x, the projects will stay on 1.x.
This is on Confio. As part of it, Confio supports tools that are happy to support 2.0, which is a mutual gain here. Also important point here. As far as I understand, cw-orchestrator targets new contracts. An important point here is that there is absolutely no reason to create smart contract using CW 1.x ever at this point. 1.x branch will be supported for existing contracts, so the security patches would be backfixed, but new contracts should use stable 2.x line. The fact that chains are not yet upgraded is not an argument here - cw-std 2.x is compatible with 1.x runtime (proper feature flag is to be set).
Therefore after careful consideration, we are happy to deliver this feature, but not to backport it to 0.11 as it is too much overhead and we want to focus on 2.x.

[Kayanski]

Agreed !
Just wanted to mention that cw-orchestrator is really suited for ANY project ! Not only new contracts.
We will come back on here once cw-orch is updated to cosmwas-std 2.x though :)

[kulikthebird]

PR #388 will allow developers to forward attributes to all message structs and enums. Additionally, it will be possible to forward attributes to enum variants. This solution resolves the issue, as the cw-orch derive macros and attributes specified in sylvia contracts and interfaces will be forwarded to the generated messages.