feat: add cargo pkgid support for cargo-script

[Rustin170506]

What does this PR try to resolve?

close #14831

In this PR, we added the cargo pkgid support for the cargo-script.

For the package itself:

cargo pkgid --manifest-path foo.rs
path+file:///my-project/foo.rs/foo#0.86.0

For its dependence:

cargo pkgid --manifest-path foo.rs -p sqlx
registry+https://github.com/rust-lang/crates.io-index#sqlx@0.7.4

How should we test and review this PR?

I have updated the unit tests and also added more test cases for it.

Additional information

None

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Another test we'll need is that we error when a cargo script is specified as a dependency which might become possible with this change.

[Rustin170506]

Another test we'll need is that we error when a cargo script is specified as a dependency which might become possible with this change.

Do you mean by cargo pkgid --manifest-path foo.rs -p foo?

[epage]

I mean

[package]
name = "foo"

[dependencies]
bar.path = "bar.rs"

[Rustin170506]

@epage dedc674 (#14961)

I just did a really rough commit to prove the idea here. It seems to work. But the code is totally messed up.

I want to check two things with you before I move forward and improve the code.

1. Can you take a grlance at the implementation, I think we have to change the SourceId and PackageIdSpec. I just want to check if I am on the right track.
2. I am a little hesitant that should we include the filename or just mark it is embedded. Since from the RFC, we don't allow users to specify the name at all, it seems the information is enough to construct the filename. But I also believe that including the full name would be easier to use and expand in the future. So I am not sure what is your thought.

[epage]

I am a little hesitant that should we include the filename or just mark it is embedded. Since from the RFC, we don't allow users to specify the name at all, it seems the information is enough to construct the filename. B

The RFC says package.name is defaulted but users can set it.

package.name cannot be mapped unambiguously back to a file name because we sanitize it

cargo/src/cargo/util/toml/embedded.rs

Line 115 in 0499e31

let name = sanitize_name(file_stem.as_ref());

cargo/src/cargo/util/toml/embedded.rs

Lines 147 to 176 in 0499e31

	/// Ensure the package name matches the validation from `ops::cargo_new::check_name`
	fn sanitize_name(name: &str) -> String {
	let placeholder = if name.contains('_') {
	'_'
	} else {
	// Since embedded manifests only support `[[bin]]`s, prefer arrow-case as that is the
	// more common convention for CLIs
	'-'
	};
	let mut name = PackageName::sanitize(name, placeholder).into_inner();
	loop {
	if restricted_names::is_keyword(&name) {
	name.push(placeholder);
	} else if restricted_names::is_conflicting_artifact_name(&name) {
	// Being an embedded manifest, we always assume it is a `[[bin]]`
	name.push(placeholder);
	} else if name == "test" {
	name.push(placeholder);
	} else if restricted_names::is_windows_reserved(&name) {
	// Go ahead and be consistent across platforms
	name.push(placeholder);
	} else {
	break;
	}
	}
	name
	}

[epage]

Can you take a grlance at the implementation, I think we have to change the SourceId and PackageIdSpec. I just want to check if I am on the right track.

    // FIXME: It should be `path+[ROOTURL]/foo#script.rs@0.0.0`.
    p.cargo("-Zscript pkgid --manifest-path script.rs")
        .masquerade_as_nightly_cargo(&["script"])
        .with_stdout_data(str![[r#"
path+[ROOTURL]/foo#script@0.0.0
"#]])

this should instead be

    // FIXME: It should be `path+[ROOTURL]/foo/script.rs#0.0.0`.
    p.cargo("-Zscript pkgid --manifest-path script.rs")
        .masquerade_as_nightly_cargo(&["script"])
        .with_stdout_data(str![[r#"
path+[ROOTURL]/foo/script.rs#0.0.0
"#]])

according to #14831 (comment)

Switching to that scheme should simplify the code, not requiring updates to PackageIdSpec, PackageId, or SourceId struct fields, only functions

[Rustin170506]

The RFC says package.name is defaulted but users can set it.

Oh, I misunderstood package.name = <slugified file stem>. I thought it always used the file name.

package.name cannot be mapped unambiguously back to a file name because we sanitize it

Yes. Got it.

[Rustin170506]

this should instead be

    // FIXME: It should be `path+[ROOTURL]/foo/script.rs#0.0.0`.
    p.cargo("-Zscript pkgid --manifest-path script.rs")
        .masquerade_as_nightly_cargo(&["script"])
        .with_stdout_data(str![[r#"
path+[ROOTURL]/foo/script.rs#0.0.0
"#]])

according to #14831 (comment)

Switching to that scheme should simplify the code, not requiring updates to PackageIdSpec, PackageId, or SourceId struct fields, only functions

So I guess if the package name is foo, then we have:

path+[ROOTURL]/foo/script.rs#foo@0.0.0

[epage]

So I guess if the package name is foo, then we have:

path+[ROOTURL]/foo/script.rs#foo@0.0.0

If the user explicitly overrode it, yes

[Rustin170506]

🔢 Self-check (PR reviewed by myself and ready for feedback.)

[Rustin170506]

I am not sure if this is the best place to check this. Maybe we should move it to where we create the source ID?

[epage]

imo this feels too spooky as this function is not directly tied to dependencies.

[Rustin170506]

Then I guess we should do the check when we read the manifest file.

[Rustin170506]

Or the dependency resolution phase. Maybe do it when resolving dependencies makes more sense.

[epage]

Maybe it isn't so bad? If we view the lack of dependency / workspace support as not far away, this just needs to hold us over until then. If its far away or unlikely, then more care might be needed.

[Rustin170506]

If we view the lack of dependency / workspace support as not far away, this just needs to hold us over until then.

Do you have any plans for these features? They sound like big features. So I would prefer to find a better place for it. At least we could move it to the earlier stage, for example when we build the source for this package?

[epage]

Dependency support is dependent on either

• [lib] support which is hazy
• artifact dependencies which I'd really like to move forward for build script delegation

Workspace support could be really useful for cargo-xtasks

These were deferred out of the first RFC just to focus on the minimal, core feature set. I am not lined up to immediately follow with these features but I could see them being high demand when this gets stabilized.