-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Closed
Labels
C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewZ-scriptNightly: cargo scriptNightly: cargo script
Description
Problem
ref #12207 (comment)
For now, if you try to use cargo pkgid
against to a cargo script file. It will generate an error:
cargo pkgid sql2.rs
error: could not find `Cargo.toml` in `/Users/rustin/code/rs-scripts` or any parent directory
Proposed Solution
We need to support cargo pkgid
for cargo-script.
For instance, for itself, it would look like:
$pwd
/Users/rustin/code/rs-scripts
$ls
sql.rs sql1.rs sql2.rs sql3.rs sql4.rs sql5.rs sql6.rs sql7.rs sql8.rs sql9.rs
$cargo pkgid sql2.rs
path+file:///Users/rustin/code/rs-scripts/sql2.rs#embedded
For its dependencies, it would look like:
cargo pkgid sql2.rs -p clap
https://github.com/rust-lang/crates.io-index#clap:4.5.21
Notes
Not sure specifying the rust file as an argument is a good idea. Because cargo pkgid
itself already takes the SPEC
as the argument. So it might be a very confusing syntax.
Metadata
Metadata
Assignees
Labels
C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewZ-scriptNightly: cargo scriptNightly: cargo script
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
weihanglo commentedon Nov 16, 2024
I've tried thinking it hard but not sure about the use case of getting
pkgid
from a cargo script. Mind sharing more on your thought?epage commentedon Nov 16, 2024
This is less about the specific command and more about all of the places
PackageIdSpec
is exposed to the user and making sure we define something that we want to stabilize rather than accidently leaking the current implementation and being stuck.weihanglo commentedon Nov 17, 2024
Regarding that, I feel like this should not block the stabilization. Unless there is a clear use case we want to support, I'd suggest we make sure pkgid not leaking when stabilization.
Adding an explicit unsupported statement is also helpful, since we can mark it as a bug if we any unexpected stuff is exposed.
0xPoe commentedon Nov 18, 2024
I think a reasonable use case is that we don't include the
cargo.lock
file under the script file dir. So there is no good way to know which version your dependency is using. So can we just get it with this command and use that specification?epage commentedon Nov 18, 2024
@weihanglo package ids come up in
cargo pkgid
as an output--package
cargo metadata
as an output (fix(metadata): Stabilize id format as PackageIDSpec #12914)cargo <cmd> --message-format json
as an output (fix(json-msg): use pkgid spec in in JSON messages #13311)cargo metadata
cargo <cmd> --package
as an inputI don't see it being practical to skip this step to stabilizing this feature.
epage commentedon Nov 18, 2024
My hope is we can get away without a
#
or?
for this. It puts it completely on theSource
to then disambiguate whethersql2.rs
is a file or a directory.One problem with this is it is inferring
--manifest-path
off ofspec
. That is a very sketchy thing to be doing. If we remove that, this becomesAt which point, the value of using a cargo-script file in a
<spec>
is greatly diminished because a cargo-script's workspace can only have one member.Having a short-hand for
PackageidSpec
is also not required for the first release of cargo script.I would suggest we defer out a short-hand until someone requests it of us with a use case.
weihanglo commentedon Nov 18, 2024
By practical, did you mean from a technical perspective it's hard to make them out of the stabilization?
I don't object to treating them stabilization blockers, as I am fine with them being unstable for a few more months. It was just these usages don't look like worth waiting for six more months. The current feature set (without pkgid/fmt/clippy) of
-Zscript
has covered 80% of its use cases. I have no data though.Could you share a practical use case of it? Anyway, I feel like a rename of the script can fix 90% of issues like this.
epage commentedon Nov 18, 2024
To clarify, I'm not saying that using
--package
is needed for cargo-scripts but that some third-party tools are likely to always pass in--package
because of confusion within the workspace. If we then take one of these tools and run them on a cargo-script, they will fail and either the user has to live with that or the maintainer has to detect a cargo-script is being used and special case it.I don't know if I can name a specific concrete example of one that does this today but that I've personally run into enough
--package
problems by-hand and programmatically, that I view it as nearly essential for programmatic use.weihanglo commentedon Nov 18, 2024
Agree we shouldn't bother short-hand at this moment.
One thing may be related to pkgid is executing a remote script. Something like
cargo https://github.com/rust-lang/cargo/path/to/script
, where the URL may be a representation of pkgid. Personally I would defer any kind of remote script execution, or even just ban this feature. Whoever want to execute a remote script should usecurl + cargo
combination, such asAnd if we ever want to support this combo, what does its pkgid look like?
epage commentedon Nov 18, 2024
Yes.
The stated goal in the RFC is for first-class support. If we wanted something that half-way worked, we could have kept to
cargo-script
.I personally am regularly annoyed with the lack of
cargo fmt
support in each of my throw-away scripts I write. I share these in bug reports and don't want to manually clean up the code for them to be presentable to the user. I've also heard of lots of reports of people who want to replace their long-lived bash and python scripts with Cargo scripts which entails wanting standard tooling compared to a throw-away script.Granted, how much we have stable in the first release is open for discussion. That depends on what level of quality people will expect from it being stable. However, as I said before, I don't see a way for us to have the package id spec format for cargo-scripts to be unstable.
19 remaining items