Added rules_rust prefix to transitive workspace names.

[UebelAndre]

I prefer all repositories/transitive workspaces generated by any repository to use the repository name as a prefix (or be user defined). This helps me quickly identify where things came from when crawling output_base.

For me this is minor improvement when debugging things.

Requires:

• Organized examples #803

[UebelAndre]

I'm pretty confused as to why I'd be getting these errors on windows...

error[E0463]: can't find crate for `rustc_std_workspace_core` which `std` depends on

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.

edit:
It seems this issue stems from the file path on windows being too long. I'm not sure if there's a better way to handle this...

@hlopko do you have any thoughts? I see you've got a TODO in this code so hopefully you'll have some context 😅

[UebelAndre]

It seems this issue stems from the file path on windows being too long. I'm not sure if there's a better way to handle this...

@hlopko do you have any thoughts? I see you've got a TODO in this code so hopefully you'll have some context 😅

This seems to have been the case. I'm surprised rustdoc_test is so prone to this issue but maybe it's related to the batch script that orchestrates running the test?

rules_rust/rust/private/rustdoc_test.bzl

Lines 155 to 188 in 26f0b03

	_rustdoc_test_batch_script = """\
	{rust_doc} --test ^
	{crate_root} ^
	--crate-name={crate_name} ^
	{flags}
	"""
	def _build_rustdoc_test_batch_script(ctx, toolchain, flags, crate):
	"""Generates a helper script for executing a rustdoc test for windows systems
	Args:
	ctx (ctx): The `rust_doc_test` rule's context object
	toolchain (ToolchainInfo): A rustdoc toolchain
	flags (list): A list of rustdoc flags (str)
	crate (CrateInfo): The CrateInfo provider
	Returns:
	File: An executable containing information for a rustdoc test
	"""
	rust_doc_test = ctx.actions.declare_file(
	ctx.label.name + ".bat",
	)
	ctx.actions.write(
	output = rust_doc_test,
	content = _rustdoc_test_batch_script.format(
	rust_doc = toolchain.rust_doc.short_path.replace("/", "\\"),
	crate_root = crate.root.path,
	crate_name = crate.name,
	# TODO: Should be possible to do this with ctx.actions.Args, but can't seem to get them as a str and into the template.
	flags = " ^\n ".join(flags),
	),
	is_executable = True,
	)
	return rust_doc_test

This could probably be tracked by #804 but it's likely not specific to sandboxing and really more windows specific. I'm unfortunately no windows expert so issues on that platform are hard for me to interpret.

[hlopko]

@hlopko do you have any thoughts? I see you've got a TODO in this code so hopefully you'll have some context sweat_smile

I'm not sure I follow, what code is that? Can you send me a link?

[UebelAndre]

I'm not sure I follow, what code is that? Can you send me a link?

rules_rust/rust/private/rustdoc_test.bzl

Line 101 in 0d98d6b

# TODO(hlopko): use the more robust logic from rustc.bzl also here, through a reasonable API.

Your name was there which is why I pinged you 😅 There's otherwise no specific code I had in mind aside from the rustdoc_test rule in general, which wasn't working at the time. I've since concluded the issue was windows max path limitations.

[hlopko]

So what is the desired resolution here?

Thinking about the problem you're solving, does it need to be solved? Examples should not be included in rules_rust releases, people should not use them from monorepos, people should not put local_repository into their WORKSPACE to make examples work.

Therefore, renaming examples -> rules_rust_examples will only be visible to people who ran bazel in the rules_rust checkout locally. From those people, only very few will ever need to debug execroot content, and IMHO to those it will be more expected to see 'examples' repository that covers /examples directory, and not rules_rust_examples that covers /examples directory.

And there should never be a naming conflict in rules_rust (we should never have multiple repositories named examples).

What do you think?

[UebelAndre]

So what is the desired resolution here?

Thinking about the problem you're solving, does it need to be solved? Examples should not be included in rules_rust releases, people should not use them from monorepos, people should not put local_repository into their WORKSPACE to make examples work.

Therefore, renaming examples -> rules_rust_examples will only be visible to people who ran bazel in the rules_rust checkout locally. From those people, only very few will ever need to debug execroot content, and IMHO to those it will be more expected to see 'examples' repository that covers /examples directory, and not rules_rust_examples that covers /examples directory.

And there should never be a naming conflict in rules_rust (we should never have multiple repositories named examples).

What do you think?

This to me is a minor readability improvement which I'd only ever expect to impact maintainers. My thought here aligns with what I mentioned on #830 where I'd like docs and examples to not be something loaded by the top level workspace so the name of the repository should have very little significance in that case and think a prefix would be a good quality of life improvement.