depend-o-pocalipse

[gilescope]

Fortune favors the brave.

There seem to be a few dependencies that I can get it to compile without it needing them.

Todo:

• unused dependencies removed
• unused dev dependencies included.
• green build
• check cumulus build
• check frame-benchmarking
• check try-runtime
• mention on community channel

[shawntabrizi]

How do you identify these? Some tool/script?

[gilescope]

Yup, cargo metadata on the workspace, then cargo edit's cargo rm on each dep and cargo check --all-targets to see if it built afterwards. record good results to a file and then git reset --hard and try a different dep.

It ran all night but it seemed to not do too bad a job.... The down side is I don't have enough color to know if there's any reason we can't remove these dependencies. This is where I need your help to point out anything deeply suspicious - "surely that crate's used by x" etc.

I'm going to have a follow up PR that does the same but for dev-dependencies but I want to land them separately.
(We can brush up the function into something nice and put it into cargo unleashed if it is useful to people - there's already a subcommand in cargo-unleash that does something in this direction but isn't quite as brute force.)

[gnunicorn]

Neat. Nothing too suspicious coming up glancing over them, there's a good chance these are indeed not needed (anymore).

But two questions on your process, just to make sure we don't accidentally dropped one too many:

1. did you build in release-mode(, too)?
2. have the frame/pallets been build for wasm/no_std?

[gilescope]

Both good questions. I did build a couple of pallets - is there a Cargo.toml with all the no_std crates in as a workspace? Or will all frame & pallets cover it? I was assuming CI tested release mode as well as wasm - there were certainly some wasm ci errors initially. Will run a few more checks and will report back here.

…

On Fri, 30 Jul 2021 at 09:36, Benjamin Kampmann ***@***.***> wrote: ***@***.**** approved this pull request. Neat. Nothing too suspicious coming up glancing over them, there's a good chance these are indeed not needed (anymore). But two questions on your process, just to make sure we don't accidentally dropped one too many: 1. did you build in release-mode(, too)? 2. have the frame/pallets been build for wasm/no_std? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9450 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCGG5OOUTRM2O7MWZMTT2JQBPANCNFSM5BDZUL5Q> .

[gilescope]

Release build is clean. I'm unclear at the moment how to build just the wasm for the whole workspace.

[gui1117]

The pallet/frame crate should be good if a release build of node-runtime is done.

I have to look again once done

[gilescope]

self_destruct_works test failure is a bit of a problem. If I do rm Cargo.lock; rm ../../Cargo.lock; cargo clean; cargo test self_destruct from frame/contracts I can reproduce this test failure on master and master a couple of months back. Possibly what's happening is a change in the Cargo.lock changes the dependencies and a different rent is applied? It doesn't seem to have anything to do with this branch.

[gilescope]

Ok test failure was just due to later wat crate being included in Cargo.lock leading to slight increase in wasm size leading to increased rent leading to test failure.

[athei]

Yup, cargo metadata on the workspace, then cargo edit's cargo rm on each dep and cargo check --all-targets to see if it built afterwards. record good results to a file and then git reset --hard and try a different dep.

Did you try cargo-udeps?

[gilescope]

I did try udeps but it wasn't that helpful for me. I coded up something that was very dumb (and inefficent) but was reasonably effective because it didn't try and do anything fancy.

[gilescope]

(There's some auto-formatting of the toml files going on here which is nice, though unclear how vscode is managing this?)

[gilescope]

Aside from the above no other .rs has been changed - the others are just cargo fmt. (Potentially we should pin the compiler via a rust-toolchain.toml so that we manage when we take these rustfmt changes)