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

[serban300]

Just left a nit. Otherwise looks good

[serban300]

I don't think we need to put this logic in a separate function and file if we don't need to reuse it.

[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/13875873988
Failed job name: fmt

[seemantaggarwal]

/cmd fmt

[serban300]

Looks good

[skunert]

Looks good!

[iulianbarbu]

LGTM!