Overwrite `$CARGO` when the current exe is detected to be a cargo
binary.
From
https://github.com/rust-lang/cargo/issues/15099#issuecomment-2666737150:
> opt-in behavior (set by cargo-the-bin):
>
> 1. `from_current_exe` if its `cargo[EXE_SUFFIX]`
> 2. `from_argv` if its `cargo[EXE_SUFFIX]`
> 3. `from_env`
> 4. `from_current_exe`
> 5. `from_argv`
r? @epage
### What does this PR try to resolve?
The old behavior gets members from `default-members` if specified in a
virtual workspace, this PR gets all workspace members for `Available`
target hints.
Fixes https://github.com/rust-lang/cargo/issues/14544
### How should we test and review this PR?
The first commit added the test, the second commit addressed the issue.
### Additional information
### What does this PR try to resolve?
Just found we can simplify `human_readable_bytes` a bit.
This also remove the `bytesize` dependency,
since we already have a hand-rolled function.
(It is a good crate, though)
### How should we test and review this PR?
Should have no real functional difference.
`cargo package` starts reporting IEC (KiB) instead of SI (KB).
So do some thresholds of `cargo package`.
Could also switch entirely to `bytesize` if that is preferred.
### Additional information
When `--exclude-lockfile` is enabled,
`cargo package` will not verify the lock file if present,
nor will it generate a new one if absent.
Cargo.lock will not be included in the resulting tarball.
Together with `--no-verify`,
this flag decouples packaging from checking the registry index.
While this is useful for some non-normal workflows that requires
to assemble packages having unpublished dependencies.
It is recommended to use `-Zpackage-workspace` to package the entire
workspace, instead of opting out lockfile.
After dd698ff0483bda065d1f78968e70ee86fb116a72,
`cargo package --no-verify` at least fails in three different cases:
* An unpublished package depending on itself as a dev-dependency (cyclic self-referential dev-dependencies).
* Can be resolved by removing the `version` field from the affected dev-dependency.
* `-Zpackage-workspace` doesn't help with it.
* Existing `cargo package` has `--package <pkg>` specifying certain unpublished packages.
* Can be resolved by specifying all unpublished packages in one `cargo` call.
* `-Zpackage-workspace` also requires all dependency versions available in the target registry when calling, so doesn't help.
* `cargo package --no-verify` has been used as a kind of “plumbing commands” to create tarballs without considering dependency orders. The use cases include:
* Preparing tarballs for other package managers.
* Integrating into custom develop workflows for unpublished/internal crates.
* Constructing custom/private registries.
This commit shows the former two cases.
### What does this PR try to resolve?
This was reported at
https://github.com/rust-lang/cargo/issues/10948#issuecomment-2674289330
For the exact mapping between the publish payload and the index,
see
https://doc.rust-lang.org/cargo/reference/registry-index.html#json-schema,
particularly the note about differences.
### How should we test and review this PR?
### Additional information
I suspect there is a second bug here because my debugging only showed us
hitting this scenario for `val-json` and not `concepts` and only when
building `utils`. That difference in behavior between a transitive and
direct dependency is odd.
It's very common for users to attempt to use the pseudo-URLs that GitHub
or other providers provide in the form
`git@github.com:rust-lang/rust.git` as a source in Cargo.toml, which are
the default format accepted by OpenSSH. Unfortunately, these are not
actually URLs, and unsurprisingly, the `url` crate doesn't accept them.
However, our error message is unhelpful and looks like this:
invalid url `git@github.com:rust-lang/rust.git`: relative URL without a base
This is technically true, but we can do better. The user actually wants
to write a real SSH URL, so if the non-URL starts with `git@`, let's
rewrite it into a real URL for them to help them and include that in the
error message.
`git@` is the prefix used by all major forges, as well as the default
configuration for do-it-yourself implementations like Gitolite. While
other options are possible, they are much less common, and this is an
extremely easy and cheap heuristic that does not necessitate complicated
parsing, but which we can change in the future should that be necessary.
This also avoids the problem where users try to turn the pseudo-URL into
a real URL by just prepending `ssh://`, which causes an error message
about the invalid port number due to the colon which they have not
changed. Since they can just copy and paste the proposed answer,
they'll be less likely to attempt this invalid approach.
### What does this PR try to resolve?
This is a part of #12207
Now that the experiment is over and we can be intrusive, this merges all
of the permanent cargo-script manifest logic into the regular manifest
loading code path with the goal of reducing the number of places people
need to be aware to check to know how things work so we're less likely
to overlook them (e.g. `package.name`s being optional). This should also
make error reporting better as we will eventually only use the real
manifest users specify, instead of one with a lot of edits by us.
This comes at the cost of some uglier code needed to check some of these
cases.
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/12978
currently, if `--package `and `--workspace` passe in the same time, the
`--package` will be ignore even the package doesnt exist in the
workspace, this PR regards this behavior as an error
### How should we test and review this PR?
one commit add test, one commit fixes the issue.
### Additional information
This makes the cache tracking synchronization code resilient to
unexpected files in the cache directory. Previously the code was
assuming that all entries in paths like `registry/index/*` are
directories. However, in circumstances like opening the directories in
macOS's finder, that can create files called `.DS_Store`. This caused it
to fail to scan within that path, since it isn't a directory.
This could in theory be made stricter, such as expecting directories to
have a particular pattern for its name. However, it seems like we never
enacted restrictions on what names are used for the git directories, so
it wouldn't work very well for that. Though that is something we could
consider in the future.
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/14831
In this PR, we added the `cargo pkgid` support for the cargo-script.
For the package itself:
```console
cargo pkgid --manifest-path foo.rs
path+file:///my-project/foo.rs/foo#0.86.0
```
For its dependence:
```console
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
The left-aligned error message is there to
workaround rustfmt refusing to format files
which contain string literals which are too
wide. I have not found a consistent way to
fix this behaviour, but left-aligning does
resolve it in this case. I believe that this
should have an explanatory comment, but code
review determined that to be "noise" and so
I removed it.
