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

[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

[iulianbarbu]

The parachain template workspace still fails to build and the error originates in the prefix_logs_with macro.

[seemantaggarwal]

The parachain template workspace still fails to build and the error originates in the prefix_logs_with macro.

yeah, I will take a look, I am not entirely sure why and what other options i can try, clearly tried quite a few things. i am still confused as to why cargo build works but cargo nexttest run fails

[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