-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement rm-override #133
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fantastic! Thanks so much for working on this.
I've left some comments on some minor things, but overall this is great. There's also one test that's failing in CI, but it looks like it's just an outdated snapshot.
There are a couple of other things that would be nice to have before merging.
- A test or two like the ones in
tests/all/main.rs
that callscargo rm-override
usingassert_cmd::Command
. You can copy what this function is doing.
This is useful since it tests the entire command end-to-end, not just thepatch_manifest
function. - A test similar to this one which tests the output of
cargo rm-override --help
.
Let me know if there are any parts of my review that don't make sense, or that you need help with :)
src/toml.rs
Outdated
name: &str, | ||
registry: &str, | ||
mode: &context::Mode, | ||
op: Operation, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'm not sure we need this Operation
type. I think this could be better off with this function removed, and just using add_patch_to_manifest
and remove_patch_from_manifest
directly, even if the below block of code needs to be duplicated and moved into those functions
let mut manifest: toml_edit::DocumentMut = manifest
.parse()
.context("patch manifest contains invalid toml")?;
let manifest_table = manifest.as_table_mut();
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have something in mind why to remove the single interface? I thought of using a struct, maybe named Manifest
, which exposes the functions add_override
, remove_override
and perhaps later list_overrides
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of just having a two separate independent free functions, but a struct would also work great 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That being said this, is a small thing so it's up to you if you'd like to change it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only a partial review, since I have to go AFK now. I'll review some more when I get back
Sorry that the feedback loop from CI has been slow. Once you've got commits in main
, it won't need to be constantly approved to run.
@@ -17,6 +17,11 @@ pub enum CargoInvocation { | |||
#[command(name = "override", about)] | |||
#[command(next_line_help = true)] | |||
Override(Override), | |||
|
|||
/// Remove an override from the `[patch]` section of `Cargo.toml`s for a package. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Remove an override from the `[patch]` section of `Cargo.toml`s for a package. | |
/// Remove an existing override from the `[patch]` section a `Cargo.toml`. |
@@ -25,7 +25,7 @@ use tempfile::TempDir; | |||
use test_case::test_case; | |||
|
|||
#[googletest::test] | |||
fn patch_transative_on_regisrty() { | |||
fn patch_transitive_on_registry() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing these typos 🙌
Ok(manifest) | ||
fs::write(&manifest_path, &project_manifest_toml) | ||
.context("failed to write patched `Cargo.toml` file")?; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably print something out when the removal was successful.
Something similar to what we do for adding patches.
Lines 161 to 164 in 7050e77
eprintln!( | |
"Patched dependency \"{}\" on registry \"{registry}\"", | |
patch_manifest.name | |
); |
src/toml.rs
Outdated
name: &str, | ||
registry: &str, | ||
mode: &context::Mode, | ||
op: Operation, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of just having a two separate independent free functions, but a struct would also work great 👍
Could you check the failed tests, please? These fail because the existence of the manifest is checked before the package details are built. Is it ok to adopt the output errors in the tests, or does these tests have to be changed? |
@teamplayer3, I'm ver sorry I took a whole week to responded. Last week was particularly busy at work so I didn't get many chances to look at open source. I'll also check out your other PR as soon as I get the chance. The changes to the output look fine. Feel free to adopt the new output in the tests 👍 . Once that's done, I think I'm happy to merge |
I think, as described in #147 (comment), we can remove snapshots that assert on |
Maybe there are two points we can learn of these specific tests. First we recognize something like in #155. Secondly, the error could be too complicated and should be simplified and be implemented by cargo-override, maybe. Yeah, it could be too picky. |
resolves #130
Implementation Open Questions