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

[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(),
		},
	};

[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

[seemantaggarwal]

Summary of next round of try outs, based on feedback and suggestions

1. Node already has sc-tracing as suggested by Serban

But, here is what I further tried:

1. I added polkadot-sdk = { workspace = true, features = ["substrate-build-script-utils", "node"] } as a build dependency as well, note: it already existed as a dependency too
2. Also tried modifying the
   `
   -#[cfg(feature = "sc-tracing")]

• #[cfg(feature = "node")]
  `
  The error here is: I should not modify the umbrella/src/lib.rs directly

3. I also tried adding
   `
   #[cfg(feature = "sc-tracing")]

• pub use sc_tracing::logging;
  `
  It gave the same error as above

4. Also tried import use polkadot_sdk::sc_tracing::logging; in the service.rs and then using logging

Another common theme amongst these approaches is
It works on running cargo build, but fails on running cargo nextest run --workspace --features runtime-benchmarks benchmark --locked --cargo-profile testnet --cargo-quiet

What are my options further:

1. I can modify the generate-umbrella.py to add
   `#[cfg(feature = "sc-tracing")]

• pub use sc_tracing::logging;`

that seems the most promising, although I am not sure of the outcomes against CI, I will have to try

@serban300 @kianenigma @iulianbarbu

[ggwpez]

Please check how this is used; path sc-tracing::logging makes sense, but polkadot-sdk::logging does not.
It needs to be changed in this case to polkadot-sdk::sc-tracing.

[serban300]

Used generate_access_from_frame_or_crate

fixed

[seemantaggarwal]

lgtm!

[seemantaggarwal]

maybe we can document this somewhere? what this is?

[serban300]

There is a comment above the function definition:

/// Generate the crate access for the crate using 2018 syntax.
///
/// If `frame` is in scope, it will use `polkadot_sdk_frame::deps::<def_crate>`. Else, it will try
/// and find `<def_crate>` directly.

[iulianbarbu]

This functionality seems to be shared between frame and substrate client. I would not pull in frame namespaced crates as dependencies for substrate/client crates (FYI, a quick fuzzy search for frame in substrate/client is not referencing any frame dependency). I wonder if we should add this (and maybe other related logic) to an existing shared place or a new one - e.g. substrate/utils (although, there isn't a crate for something like it, and we'd need to create one).

Also, the function docs miss to mention that it looks for polkadot-sdk as well.

[serban300]

Yes, also thought of that, but I don't know. I didn't completely check, but I guess frame-support-procedural-tools should contain pretty generic methods. If it does, I think we could just use it. Maybe we should rename it or move it under primitives. I have to check.

[serban300]

I'm not sure.

@ggwpez @kianenigma what do you think ?

[kianenigma]

we shouldn't bring in frame_support_procedural_tools but rather create a helper function, somewhere accessible to the tracing proc macro, that similarly resolves dependencies.

it will check if polkadot-sdk is in scope, use that, else look for the crate name directly.

It should not care about polkadot-sdk-frame, because this is all client side code, which is why I am saying we should not use frame_support_procedural_tools (other than it being a weird dependency).

[seemantaggarwal]

/cmd fmt

[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/13696677712
Failed job name: build-rustdoc