Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow sylvia crates to use cw-orchestrator as well #374

Closed
ethanfrey opened this issue May 8, 2024 · 7 comments · Fixed by #388
Closed

Allow sylvia crates to use cw-orchestrator as well #374

ethanfrey opened this issue May 8, 2024 · 7 comments · Fixed by #388

Comments

@ethanfrey
Copy link
Member

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
Copy link

adairrr commented May 8, 2024

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
Copy link
Collaborator

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
Copy link
Member Author

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
Copy link

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

I like this approach as well.

@hashedone
Copy link
Collaborator

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
Copy link

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 kulikthebird linked a pull request Jun 25, 2024 that will close this issue
@kulikthebird
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants