Follow up for: Use the umbrella crate for the parachain template #5993

[seemantaggarwal]

Resolving sc-tracing not being resolved when imported through the polkadot sdk

Will take another look when the PR is ready for review

[ggwpez]

sc-* crates are Substrate Client libraries, they should not be in the runtime feature.
Please use the generate-umbrella.py script if you want to update it.

[seemantaggarwal]

ok makes sense, was just trying an experiment, i will keep that in mind, thanks

[iulianbarbu]

The node crate still fails to build because an error is raised here during the compilation, when the macro is expanded: https://github.com/paritytech/polkadot-sdk/blob/master/substrate/client/tracing/proc-macro/src/lib.rs#L123. crate_name function searches through the node's Cargo.toml for the sc-tracing dependency, or for the renamed version of the same crate (https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#renaming-dependencies-in-cargotoml), but it can not find it, since we rely on polkadot-sdk with its node feature, which pulls the sc-tracing crate and re-exports it, and the compilation fails as a result.

I would attempt a fix in sc-tracing-proc-macro crate, maybe based on cargo-metadata (https://docs.rs/cargo_metadata/latest/cargo_metadata/), where we parse through the dependency graph. Not sure how easy it is, but I would check for our current crate dependencies, search for polkadot-sdk, and then iterate through its dependencies (and here check if sc-tracing exists ). I am not sure if sc-tracing will show up no matter what polkadot-sdk features we enable, because if this is the case, then we might report sc-tracing can be used in the crate that uses polkadot-sdk, but in practice this would fail, because no enabled features pulls it in. However, this is already better since for the cases where sc-tracing is pulled in because of an enabled feature that pulls it in, the compilation wouldn't fail (assuming use polkadot-sdk::* is used in the file where sc_tracing is used).

[seemantaggarwal]

Maybe I can try it out instead, we can discuss of what and how, that way, we try it out, and I learn something, 2 birds one stone ;)

[iulianbarbu]

Just posting the code change and the file. It successfully builds now.

	let crate_name = match crate_name("sc-tracing") {
		Ok(FoundCrate::Itself) => Ident::new("sc_tracing", Span::call_site()),
		Ok(FoundCrate::Name(crate_name)) => Ident::new(&crate_name, Span::call_site()),
		Err(_) => match crate_name("polkadot-sdk") {
			Ok(FoundCrate::Itself) | Ok(FoundCrate::Name(_)) =>
				Ident::new("sc_tracing", Span::call_site()),
			Err(_) => return Error::new(Span::call_site(), "Neither one of `sc-tracing` or `polkadot-sdk` hasn't been found in your dependencies, or no `polkadot-sdk`'s enabled feature pulls in `sc-tracing`.").to_compile_error().into(),
		},
	};

[serban300]

Left a comment.

Also as a high level suggestion, personally sometimes I find it hard to review PRs with a lot of commits. As long as the PR is not ready for review, I would just squash all the commits in a single one and force push.

Later edit: Also I think you need to update Cargo.lock. Some of the CI errors seem to be caused by this.

[seemantaggarwal]

What I have tried, outside of the current commit:

cargo tree | grep sc-tracing                             

│   │   │   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing)
│   │   │   │   │   │   │   ├── sc-tracing-proc-macro v11.0.0 (proc-macro) (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing/proc-macro)
│   │   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   │   │   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   │   │   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
│   │   ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)
    ├── sc-tracing v28.0.0 (/Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/client/tracing) (*)

Tried using explicit import for use polkadot_sdk::sc_tracing; in service.rs

Created a separate feature for tracing:
in umbrella/Cargo.toml
[features] default = ["sc-tracing"]

also as:

[features]
sc-tracing = ["dep:sc-tracing"]

and modifying the umbrella/src/lib.rs

#[cfg(feature = "sc-tracing")]
pub use sc_tracing::*;

and then importing in node/src/service.rs

#[cfg(feature = "sc-tracing")]
use polkadot_sdk::sc_tracing;

The output from:

cargo tree --features sc-tracing | grep sc-tracing

error: the package 'parachain-template-node' does not contain this feature: sc-tracing
help: packages with the missing feature: polkadot-sdk, polkadot-cli

also ran:

cargo metadata --format-version 1 | jq '.packages[] | select(.name=="polkadot-sdk") | .features'

to get

`output of cargo metadata --format-version 1 | jq '.packages[] | select(.name=="polkadot-sdk") | .features'

"sc-tracing": [
   "dep:sc-tracing"
 ],
 "sc-tracing-proc-macro": [
   "dep:sc-tracing-proc-macro"
 ],
"node":[
 "sc-tracing",
]
"sc-tracing": [
   "dep:sc-tracing"
 ],

"sc-tracing-proc-macro": [
   "dep:sc-tracing-proc-macro"
 ],`

[seemantaggarwal]

Tagging @iulianbarbu @kianenigma @serban300
For an eye/help:

As seen above in the comment, #7464 (comment)

The cargo tree suggests tracing to be under polkadot-sdk

However, in the service.rs under the parachain it is not being resolved, I have also added, what my investigation involves so far, and some further experimentation in the following commits:

ad6e74a
e2f570d

5166954

I am not sure why it is not being resolved and could use some insights into debugging

[serban300]

and then importing in node/src/service.rs

#[cfg(feature = "sc-tracing")]
use polkadot_sdk::sc_tracing;

The output from:

cargo tree --features sc-tracing | grep sc-tracing

error: the package 'parachain-template-node' does not contain this feature: sc-tracing
help: packages with the missing feature: polkadot-sdk, polkadot-cli

If you do

#[cfg(feature = "sc-tracing")]
use polkadot_sdk::sc_tracing;

than I think you also need to define a sc-tracing feature in the Cargo.toml of the parachain template node. Maybe that's the problem.

But I wouldn't do this. I wouldn't guard use polkadot_sdk::sc_tracing; with #[cfg(feature = "sc-tracing")] and I wouldn't add a sc-tracing feature in the Cargo.toml of the parachain template node. I would add the sc-tracing as a dependency of the node feature in the umbrella Cargo.toml. And then in the parachain template node, we already use this feature: polkadot-sdk = { workspace = true, features = ["node"] };

[seemantaggarwal]

Hi @serban300 I agree with . I wouldn't guard use polkadot_sdk::sc_tracing;
it was just an explicit trial

sc-tracing already exists under node btw, so I am not sure why it is unabl to resolve that

ahh reading it again:

I would add the sc-tracing as a dependency of the node feature in the umbrella Cargo.toml

Let me try this

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13485865048
Failed job name: cargo-clippy