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

Make the recursive option of cargo-sweep recurse past Cargo directories #78

Merged
merged 8 commits into from
Feb 5, 2023

Conversation

bes
Copy link
Contributor

@bes bes commented Dec 17, 2022

When passing the -r (recursive) option to cargo-sweep, it is supposed to be recursive over the subdirectories of the root path it is given (whether implicit or explicit). cargo-sweep erronously assumed that a Cargo project could not contain unrelated subprojects.

This patch lets cargo-sweep keep recursing past cargo roots.

The drawback of this patch is that cargo-sweep will need to recurse more, and as such becomes a bit slower to run.

Fixes #66

Copy link
Collaborator

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

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

Can you please add a test for the new behavior? You may need to add the project from #66 into tests, see tests/integration.rs for some existing code you can use as an example.

Otherwise this looks fine to me :) the CI failures are unrelated and should be fixed if you rebase over master.

@jyn514 jyn514 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 25, 2022
@bes bes force-pushed the cargo-sweep-actually-recursive branch 2 times, most recently from 2dd47ac to 1ff2a84 Compare January 28, 2023 22:00
@bes
Copy link
Contributor Author

bes commented Jan 28, 2023

@jyn514 I finally got some time to write an integration test, and I think it came out OK.

But I have to say, the state of the integration.rs file is not very good. I tried to improve it, but I have some... feelings.

Tests should be easy to follow step-by-step by reading the test function, but folks have tried to be too clever with the code. Deduplication, DRY, and utility functions that assume too much about how a test works will end up hurting tests as much as they help improve regular code.

I had to start by documenting a lot of the code that I didn't understand and then patch my integration test on top of that.

Furthermore, the empty_project_output didn't run locally for me. Either I broke it somehow, or the regexp was written by someone with another type of machine than me where the file system outputs files and directories in a different order. We'll see once someone approves my PR for testing. My recommendation would be to fix that test to be platform agnostic (unless I broke it, of course).

@bes bes force-pushed the cargo-sweep-actually-recursive branch from 1ff2a84 to 84fc0f9 Compare January 28, 2023 22:06
@bes
Copy link
Contributor Author

bes commented Jan 28, 2023

Yeah I just confirmed that the test empty_project_output is broken on the master branch on my machine as well (2019 intel mac)

@bes
Copy link
Contributor Author

bes commented Jan 28, 2023

The regex requires this order

        \[DEBUG\] Successfully removed: ".+libsample_project-.+\.rlib"
        \[DEBUG\] Successfully removed: ".+libsample_project-.+\.rmeta"
        \[DEBUG\] Successfully removed: ".+sample_project-.+\.d"
        \[DEBUG\] Successfully removed: ".+.fingerprint.+sample-project-.+"

But my machine outputs this order

[DEBUG] Successfully removed: "/var/folders/g8/qgn3gbf514b_p34n_jc_1_lc0000gn/T/.tmpKdJQnA/debug/deps/sample_project-f27e05aa5c13ed9b.d"
[DEBUG] Successfully removed: "/var/folders/g8/qgn3gbf514b_p34n_jc_1_lc0000gn/T/.tmpKdJQnA/debug/deps/libsample_project-f27e05aa5c13ed9b.rlib"
[DEBUG] Successfully removed: "/var/folders/g8/qgn3gbf514b_p34n_jc_1_lc0000gn/T/.tmpKdJQnA/debug/deps/libsample_project-f27e05aa5c13ed9b.rmeta"
[DEBUG] Successfully removed: "/var/folders/g8/qgn3gbf514b_p34n_jc_1_lc0000gn/T/.tmpKdJQnA/debug/.fingerprint/sample-project-f27e05aa5c13ed9b"

@bes
Copy link
Contributor Author

bes commented Jan 28, 2023

I managed to fix it by changing the regexp to this monstrosity. My guess is that regex isn't the right tool for the job, though.

        (\[DEBUG\] Successfully removed: (".+libsample_project-.+\.rlib"|".+libsample_project-.+\.rmeta"|".+sample_project-.+\.d"|".+.fingerprint.+sample-project-.+")\n{0,1}){4}

@bes bes force-pushed the cargo-sweep-actually-recursive branch from 603d59c to 8c4ca2b Compare January 28, 2023 22:48
tests/integration.rs Outdated Show resolved Hide resolved
@bes bes force-pushed the cargo-sweep-actually-recursive branch from ba43ad6 to 8b75297 Compare January 30, 2023 08:44
Copy link
Collaborator

@marcospb19 marcospb19 left a comment

Choose a reason for hiding this comment

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

LGTM, sorry my last PR gave you some conflicts xD.

These should be easy to fix because you only changed one line at main.rs, and there aren't many changes on integration.rs, here's the diff, just in case it helps.

EDIT: oh and overwrite your PR's regex pattern over mine please.

@bes bes force-pushed the cargo-sweep-actually-recursive branch 2 times, most recently from e542c06 to 48e462e Compare February 1, 2023 05:47
@bes
Copy link
Contributor Author

bes commented Feb 1, 2023

Updated

@bes bes force-pushed the cargo-sweep-actually-recursive branch from 48e462e to bf1b8a2 Compare February 1, 2023 07:46
@bes
Copy link
Contributor Author

bes commented Feb 1, 2023

Looks like there is a "bug" in format_bytes(bytes: u64), it doesn't agree with the values from the human-size crate?

human-size expects bytes to be suffixed B but format_bytes outputs the string "bytes".

@jyn514 jyn514 added S-waiting-on-review Status: Awaiting review from a maintainer and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 2, 2023
@jyn514 jyn514 self-assigned this Feb 2, 2023
Copy link
Collaborator

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

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

The source changes seem ok, but I had a few comments about the test changes - most of them are non-blocking except the fact that the test isn't actually effective.

tests/integration.rs Show resolved Hide resolved
tests/integration.rs Outdated Show resolved Hide resolved
tests/integration.rs Outdated Show resolved Hide resolved
tests/integration.rs Outdated Show resolved Hide resolved
@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from a maintainer labels Feb 2, 2023
When passing the -r (recursive) option to cargo-sweep, it is supposed to
be recursive over the subdirectories of the root path it is given
(whether implicit or explicit). cargo-sweep erronously assumed that
a Cargo project could not contain unrelated subprojects.

This patch lets cargo-sweep keep recursing past cargo roots.

The drawback of this patch is that cargo-sweep will need to recurse more,
and as such becomes a bit slower to run.

Fixes holmgr#66
The empty_project_output test doesn't have the same traversing/logging
order on macos as it does on whatever os/machine it was written for.
This commit tries to improve the situation somewhat by making the test
runnable on macos as well, while sacrificing readability and test accuracy.

An alternative fix would be to not use regex for the test at all.
There is an edge case where the `cargo test` invocation can be run with
`CARGO_TARGET_DIR` set, which needs to be handled by the recursive_multiple_root_workspaces
test since it assumes that `CARGO_TARGET_DIR` isn't set.
This commit improves the recursive_multiple_root_workspaces by applying some
review comments:
* Deduplicating the cargo command by making the cargo function take an
  absolute path instead of a relative one.
* Removing an unnecessary CARGO_INCREMENTAL=0 environment variable
* Renaming the temporary workspace directory variable
…spaces

This commit changes the recursive_multiple_root_workspaces test by adding
assertions to make sure that the actions of cargo-sweep were actually
effective in cleaning nested root workspaces.
@bes
Copy link
Contributor Author

bes commented Feb 4, 2023

The source changes seem ok, but I had a few comments about the test changes - most of them are non-blocking except the fact that the test isn't actually effective.

Fixed 👍

Copy link
Collaborator

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

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

Thanks! This looks really good :) I just have a couple nits.

tests/integration.rs Outdated Show resolved Hide resolved
tests/integration.rs Outdated Show resolved Hide resolved
tests/integration.rs Outdated Show resolved Hide resolved
tests/integration.rs Show resolved Hide resolved
* Remove a few comments that are no longer valid.
* Improve the understanding of the final assertions by adding a
  more detailed explanation.
@jyn514 jyn514 merged commit dbb2133 into holmgr:master Feb 5, 2023
@jyn514
Copy link
Collaborator

jyn514 commented Feb 5, 2023

Thanks for sticking with this!

@marcospb19 marcospb19 mentioned this pull request Sep 12, 2023
@marcospb19 marcospb19 mentioned this pull request Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Doesn't clean non-workspace crates that exist inside a workspace
3 participants