-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Not planned
Labels
A-lockfileArea: Cargo.lock issuesArea: Cargo.lock issuesC-bugCategory: bugCategory: bugS-propose-closeStatus: A team member has nominated this for closing, pending further input from the teamStatus: A team member has nominated this for closing, pending further input from the team
Description
Problem
I have a crates.io patch pointing to a git repo and branch, and the branch name contains a plus sign.
That plus sign seems to break cargo update MY_DEP
: (cargo update works fine)
urlplussign-bin on main took 1s50ms
❯ cargo update
Updating git repository `https://github.com/kaspar030/urlplussign-lib`
Updating crates.io index
Locking 1 package to latest compatible version
Removing urlplussign-lib v0.1.0 (https://github.com/kaspar030/urlplussign-lib?branch=main plus#2ff09b40)
Adding urlplussign-lib v0.1.0 (https://github.com/kaspar030/urlplussign-lib?branch=main+plus#2ff09b40)
urlplussign-bin on main took 1s4ms
❯ cargo update urlplussign-lib
Updating git repository `https://github.com/kaspar030/urlplussign-lib`
error: Unable to update https://github.com/kaspar030/urlplussign-lib?branch=main plus
Caused by:
failed to fetch into: /home/kaspar/.cargo/git/db/urlplussign-lib-a84c539888aebb72
Caused by:
'+refs/heads/main plus:refs/remotes/origin/main plus' is not a valid refspec.; class=Invalid (3)
Steps
I've built a minimal reproducer repo:
- git clone https://github.com/kaspar030/urlplussign-bin
- cd urlplussign-bin
- cargo update urlplussign-lib # fails
- cargo update # succeeds
Possible Solution(s)
No response
Notes
The plain cargo update
output looks weird, too:
Removing urlplussign-lib v0.1.0 (https://github.com/kaspar030/urlplussign-lib?branch=main plus#2ff09b40)
Adding urlplussign-lib v0.1.0 (https://github.com/kaspar030/urlplussign-lib?branch=main+plus#2ff09b40)
Note how it is Removing w/o plus sign, adding with plus sign, for the same branch.
Version
❯ cargo version --verbose
cargo 1.82.0 (8f40fc59f 2024-08-21)
release: 1.82.0
commit-hash: 8f40fc59fb0c8df91c97405785197f3c630304ea
commit-date: 2024-08-21
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w 11 Sep 2023
os: Arch Linux Rolling Release [64-bit]
Metadata
Metadata
Assignees
Labels
A-lockfileArea: Cargo.lock issuesArea: Cargo.lock issuesC-bugCategory: bugCategory: bugS-propose-closeStatus: A team member has nominated this for closing, pending further input from the teamStatus: A team member has nominated this for closing, pending further input from the team
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
esp-hal
fork ariel-os/ariel-os#499ehuss commentedon Nov 4, 2024
I believe this has already been fixed with the v4 lockfile format. v4 will be the default in Rust 1.83. The v4 format is supported back to Rust 1.78.
You can update your lockfile to v4 by deleting it and rebuilding it with the beta or nightly toolchain. Or if you are adventurous, just edit the Cargo.lock file and change the version to 4 and run
cargo update
.epage commentedon Nov 4, 2024
I just confirmed that this is related to the <=v3 lockfile formats.
epage commentedon Nov 4, 2024
v4 lockfile format will be the default (when compatible with your MSRV) as of 1.83, see #14595.
The original issue was #11085 which was fixed in #12280 and stabilized in #12852
weihanglo commentedon Nov 4, 2024
This also happens on older versions of Cargo like 1.68.0.
This seems like a corner case between updating a selected package. When
url
crate read a package source, it always URL-decodes thesource
field (no way to make it not to). Therefore, Cargo always getsSourceId
with branchmain plus
. I am not 100% sure the actual cause of this, but my gut feeling is that we might need a custom URL deserialization other than relying onurl
crate to fix this, and that means all structs, fromEncodableResolve
,EncodableDependency
,EncodablePackageId
andEncodableSourceId
needs some adjustments.weihanglo commentedon Nov 4, 2024
BTW the presence of
[patch]
is not necessary to reproduce. Simply with some special characters in a branch name would cause the failure.weihanglo commentedon Nov 4, 2024
Given the complexity (it doesn't seem hard but would need a bunch of extra code), I am not sure if it is worth a fix.
weihanglo commentedon Nov 9, 2024
While this is a nasty papercut, I propose this as a wont-fix and close this for reasons below
+
or any other URL encodable characters are already broken in one way or the other.