-
Notifications
You must be signed in to change notification settings - Fork 354
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
The contract MSRV problem in 0.16.5 #1244
Comments
Yes, this is a problem. It is a consequence of how the Rust module system works and how crate authors increase compiler requirements. There is very little we can do about it. What I did in the past is: |
I agree. It seems that this issue should be resolved in wasmer. not in cosmwasm. I will create an issue soon in wasmer.
And thank you for sharing this method. |
Coming back from the discussion at wasmer, I wonder if it would be the right thing to guide the MSRV. In the end, it seems that we have no choice and to force contract developers to use the highest version of rust possible, Even after the 1.0 release. Right now, when creating a new contract package or migrating old version contract, it seems that there is no choice but to provide a way to downgrade the dependency manually in the same way as above. |
I understood out that
hashbrown 0.12.0
used byrkyv
used by wasmer in0.16.3
creates MSRV issue.And in 0.16.4, cargo.lock seems to have been solved by pin the
rkyv
by manual.d9ea506
However, there were still concerns.
When developing a new contract, the
rkyv
version is updated again in the newly createdcargo.lock
of the new contract.This occurs because the contract's dev-dependencies refers to
cosmwasm-vm
.There is no problem with normal contract compilation. However, in rust 1.54.0, we cannot run the test logic.
Below is a reproduced example of deleting cargo.lock from the burner and testing again.
The contracts we are managing can directly modify cargo.lock in the same way, but it is difficult for other contract developers who are not aware of this issue to understand why they need to modify cargo.lock directly.
Is there any way not to modify cargo.lock in the newly created contract?
It will be solved if contract developer create it using a solved template, but if it is not, (or such as updating an existing contract), it seems that the contract developer will have to modify
cargo.lock
directly.In the end, I think it seems that this problem will be solved by pining the
rkyv
so that the MSRV problem does not occur in wasmer.Could you please tell me if I've misunderstood anything?
The text was updated successfully, but these errors were encountered: