[workspace-optimizer]: build fails if workspaces inside `contracts/*` hold path dependencies other than `contracts/*` paths

[ever0de]

If internal crates exist other than contracts/*, it seems that workspace-optimizer doesn't build with wasm target. It appears to be building with no_std, not wasm.

ex path tree)

├── contracts
│   └── counter-contract
├── crates
│   ├── msg

Here workspace-optimizer will fail if counter-contract is holding msg as path dependency.

Does anyone know anything about this?

[webmaster128]

workspace-optimizer only looks for workspace members in the contracts/ folder. If you want a contract to be built, it needs to be moved there. However, other dependencies can be in other folders. In https://github.com/CosmWasm/cw-plus there are contracts under contracts/ and helper packages under packages/. Those packages are built as part of the contract build process. They don't have their own Wasm output.

[ever0de]

workspace-optimizer only looks for workspace members in the contracts/ folder. If you want a contract to be built, it needs to be moved there. However, other dependencies can be in other folders. In https://github.com/CosmWasm/cw-plus there are contracts under contracts/ and helper packages under packages/. Those packages are built as part of the contract build process. They don't have their own Wasm output.

I will check the cw-plus repository. Thank you.

[ever0de]

Should external dependencies (those in packages/* in cw-plus) be deployed to registry(crates.io)?

[webmaster128]

packages/storage-plus is published to crates.io for sure. I don't know about the other ones.

But if they are just internal packages used in your repository, you don't need to publich them.

[ever0de]

Hmm... I don't know what cw-plus is different from my current situation.

[webmaster128]

What's your issue/error then?

[ever0de]

The situation seems the same, but I can't build.

[webmaster128]

What is "can't build"? What did you do exactly? What error do you get exactly?

[ever0de]

https://github.com/ever0de/cw-workspace-optimizer-report

Environment

• macOS Monterey 12.5 (m1)
• rust version: 1.62.0 (specified in toolchain)

Command used

docker run --rm -v "$(pwd)":/code \
   --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
   --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
   cosmwasm/workspace-optimizer:0.12.6

Failed to load from std module

What I feel while trying to reproduce a few things is that it seems to fail in version 1.62.0 of Rust.

[webmaster128]

Ahaaa, that's a nice find. Your rust-toolchain file overrides the Rust version shipped with the optimizer.

We somehow need to prevent that from happening and ensure to always use the version shipped with the optimizer. But the short term fix is to remove that file from the source code.

[ever0de]

First of all, if I were to do a self-report, I should have included the content more clearly in the first part. sorry.

If the rust-toolchain file does not exist, it works normally.

• It was confirmed that the problem was using the toolchain file, not the problem of a specific version.

Is it difficult to support toolchain files? I don't want the Rust version of my project to change suddenly and incur overhead costs.

[webmaster128]

The whole point of rust-optimizer and workspace-optimizer is to be able to create reproducible production builds. For every Rust version the output changes. For this reason, every optimizer version comes with a specific version of Rust thatr is clearly documented in the CHANGELOG of this repo. The Rust-optimizer should not download a different compiler version at runtime for simplicity.

I don't want the Rust version of my project to change suddenly and incur overhead costs.

I would not recommend that strictness. All you need to do is specify a minimal version for the project. If someone builds with a more recent version, cool. If someone builds with a version that is too old, they will get compile errors. In general it is nice of the source code compiles with a reasonably wide range of compilers. E.g. you can say you require >= 1.59, workspace-optimizer uses 1.60, your CI uses 1.62 and another developer might use latest stable 1.63. There is nothing wrong with that.

[ever0de]

I agree with your opinion. The slightly different thing is to prevent CI from failing indiscriminately (although it's actually regular) by linter rules like clippy.

Thank you very much for your reply. I don't think there will be any further problems after that, can I close the issue?

[webmaster128]

The slightly different thing is to prevent CI from failing indiscriminately (although it's actually regular) by linter rules like clippy.

In CosmWasm we do this:

• Run all CI jobs with the minimal supported version
• Have a dedicated clippy job that is run on both the min version as well as the latest stable. When updating the latest stable, we fix the clippy issues in the same PR.

I think what is left here is that the optimizer should have a better error message in case a rust-toolchain file is found.