search

killercup / cargo-edit

A utility for managing cargo dependencies from the command line.
http://killercup.github.io/cargo-edit/
MIT License
3.09k stars 148 forks source link

Cargo `set-version --workspace` does not update `Cargo.lock` with private crate reference #891

Open brogdonm opened 7 months ago

brogdonm commented 7 months ago

Apparently, when using the cargo set-version --workspace command in GitHub actions using a linux runner, the Cargo.lock file does not get updated with the updated version. When running on Windows, my WIP has a Cargo.toml and Cargo.lock change. In our scenario, the repository using the action is setup to use workspaces.

Update: Apparently, the issue recreates for windows-latest runners too. I could only recreate the issue in my sample repository once I added a private crate.

This is with the latest version: 0.12.2

epage commented 7 months ago

Can you provide local reproduction steps?

brogdonm commented 7 months ago

I setup a repository that demonstrates the issue. Check out the actions to see what I'm talking about:

Turns out, it fails on windows-latest too and from my steps of setting up a simple repository to recreate it appears to happen when there is a crate dependency that is "private".

For example, this fails: https://github.com/brogdonm/cargo-edit-issue-891/commit/fa566e159a8f7db9753e072f7f4fbb00e593386d

This does not: https://github.com/brogdonm/cargo-edit-issue-891/commit/6da6ddcd09e09f7e0a8ff35d25b0ac3bf6277755

epage commented 7 months ago

Can you provide local reproduction steps. Meaning without the use of an action

brogdonm commented 7 months ago

Yes...

brogdonm commented 7 months ago

When I was originally on Windows running locally, I was not using bash.exe as the windows-latest runner is in the referenced GH workflow, so I assume it is some weird interaction with the bash.

epage commented 7 months ago

When I ran this I got

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   Cargo.toml

no changes added to commit (use "git add" and/or "git commit -a")

$ git diff
diff --git i/Cargo.toml w/Cargo.toml
index a3f8e69..2429eff 100644
--- i/Cargo.toml
+++ w/Cargo.toml
@@ -3,7 +3,7 @@ resolver = "2"
 members = [ "cargo-edit-issue-891" ]

 [workspace.package]
-version = "0.1.0"
+version = "0.2.0"
 authors = [ "Michael Brogdon <Michael.Brogdon@monotype.com>" ]
 description = "A workspace for reproducing cargo-edit issue 891"
 edition = "2021"

$ cargo check
    Updating git repository `https://github.com/brogdonm/private-crate`
error: failed to get `private-crate` as a dependency of package `cargo-edit-issue-891 v0.2.0 (/home/epage/src/personal
/dump/cargo-edit-issue-891/cargo-edit-issue-891)`

Caused by:
  failed to load source for dependency `private-crate`

Caused by:
  Unable to update https://github.com/brogdonm/private-crate?branch=main#f33c4b65

Caused by:
  failed to fetch into: /home/epage/.cargo/git/db/private-crate-2edb19a8c0a6874c

Caused by:
  failed to authenticate when downloading repository

  * attempted to find username/password via git's `credential.helper` support, but failed

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  failed to acquire username/password from local configuration

cargo-set-version was able to update the workspace.package.version field but not the lockfile. However, no cargo commands can update the lockfile; cargo-set-version just fails silently about it.

If this is what you are seeing, I'm not sure what there is we can do about this.

brogdonm commented 7 months ago

@epage first off, thanks for your prompt replies and help. Second off, yes, this is what I'm seeing.

It seemed like this was an issue with the crate since I'm just attempting to update the version of the local crate. Even if I add --offline things do not work as expected or in the same manner as a crate without a private crate listed.

Should this issue be filed with a different crate perhaps? If so, which one does the issue belong with?

epage commented 7 months ago

From what I understand, there is no bug to fix. Cargo itself requires everything in the lockfile to be accessible. Usually that means from the original source while --offline means "only with local caches". If it isn't cached and the source isn't available, there is nothing cargo can do at this time and there is nothing cargo-set-version can do.

brogdonm commented 7 months ago

@epage would it be possible to produce an error? The silence is deafening. :)

If I do cargo update --workspace I get an error indicating the crate can't be accessed.

In the meantime, we will work around this by making sure we have the token in place for access. Thanks for your support.

epage commented 7 months ago

819 is when we first adopted the code that calls into cargo and falls back silently if the lockfile could not be generated. At that time, it was being used in more general code before we adopted it to also force generation of the lockfile.

I remember needing to do this for a reason but I don't recall the reason and not seeing any notes. I'm assuming erroring for the lockfile generation should be fine though.

As I have priorities elsewhere at the moment, I likely won't get to it for a bit but would gladly accept a contribution that changes the lockfile generation code to pass the error up.

btw so far I've seen little interest in this tool and so I haven't been putting much attention to it generally. For example,, no one has initiated the conversation on the cargo repo on whether this should be merged into cargo like cargo add, cargo rm, and soon cargo upgrade.