Skip to content
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

Open
wants to merge 29 commits into
base: main
Choose a base branch
from
Open

Implement rm-override #133

wants to merge 29 commits into from

Conversation

teamplayer3
Copy link

@teamplayer3 teamplayer3 commented Sep 12, 2024

resolves #130

Implementation Open Questions

  • use one Context for commands Override and RmOverride?
  • how to handle removing empty patch table? (See comment in Code)

Copy link
Owner

@eopb eopb left a 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 calls cargo rm-override using assert_cmd::Command. You can copy what this function is doing.
    This is useful since it tests the entire command end-to-end, not just the patch_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 Show resolved Hide resolved
src/toml.rs Outdated Show resolved Hide resolved
src/toml.rs Outdated
name: &str,
registry: &str,
mode: &context::Mode,
op: Operation,
Copy link
Owner

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();

Copy link
Author

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.

Copy link
Owner

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 👍

Copy link
Owner

@eopb eopb Sep 14, 2024

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

src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@teamplayer3 teamplayer3 requested a review from eopb September 14, 2024 16:36
Copy link
Owner

@eopb eopb left a 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.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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() {
Copy link
Owner

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")?;

Copy link
Owner

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.

cargo-override/src/lib.rs

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,
Copy link
Owner

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 👍

src/context.rs Outdated Show resolved Hide resolved
@teamplayer3
Copy link
Author

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?

@eopb
Copy link
Owner

eopb commented Sep 22, 2024

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

@teamplayer3
Copy link
Author

teamplayer3 commented Sep 25, 2024

In test patch_path_doesnt_exist I have problems filtering the os error. @eopb have you an idea how to write the regex for it? Related to #147 .

@eopb
Copy link
Owner

eopb commented Sep 28, 2024

In test patch_path_doesnt_exist I have problems filtering the os error. @eopb have you an idea how to write the regex for it? Related to #147 .

I think, as described in #147 (comment), we can remove snapshots that assert on cargo metadata output. assert.failure() should be enough for these cases where the output is so fragile.

@teamplayer3
Copy link
Author

I think, as described in #147 (comment), we can remove snapshots that assert on cargo metadata output. assert.failure() should be enough for these cases where the output is so fragile.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add possibility to revert the override
2 participants