Reduce reliance on polkadot-sdk

[dandanlen]

Hi there! Related to something that was mentioned in #1888 :

Exactly; it's basically an API client to give a nice interface over interacting with the node RPCs at its core, which means we want it to be fairly independant from substrate code for the reasons Niklas mentioned!

We are in the process of upgrading our subxt version to 0.39 to take advantage of loading metadata from wasm (cool feature btw). We noticed that subxt now imports the whole polkadot-sdk by default. This seems to contradict the statements made in the above issue that subxt tries to be independent. In our case, for example, polkadot-sdk brings with it a huge number of additional indirect and unused dependencies - pallets, parachains, consensus etc. - when all we are interested in is core substrate interop. All the pallet-specific bits should come from the metadata, right?

Are there any plans to mitigate this in future (or ways to do it already)? For example I could imagine there being a polkadot-sdk with optional features so that you don't get eg. all of the frame pallets by default.

[niklasad1]

I think it's basically a cargo thingy because subxt now is using the polkadot-sdk umbrella crate and it can't know which features are enabled if "you are a library". For binary crates I expect those unused features/dependencies to be stripped away

By default subxt only depends on "polkadot-sdk/sp-crypto-hashing" but if you using the loading of metadata via wasm that requires more dependencies.

We can get rid off the polkadot-sdk umbrella crate to avoid such annoying dependency tree but the direct dependencies in subxt should be same as before.

Sorry about that let's revert the polkadot-sdk umbrella crate usage then.

[dandanlen]

Thanks for the quick reply!

I agree I think cargo/rustc are smart enough to strip away unused dependencies from the binary, but I assume they still would be downloaded, compiled etc, which would make things like CI or even local development (rust analyzer) much slower. I haven't actually measured this, it's mostly an assumption.

FYI as an example: this PR is where we update subxt. Note > 6000 line changes in the Cargo.lock file: these are all the additional SDK dependencies that we don't use (and neither does subxt I guess).