-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add a function to compare the contents of two packets. #147
Conversation
f6b6cbe
to
9be0906
Compare
7275d4a
to
5fd1b5f
Compare
22dd986
to
72ef3cb
Compare
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 - this is looking great. Some broad comments about the comparison here, which I'm happy to litigate further in a conversation before you do any more implementation if you prefer!
ids <- c(...) | ||
replacements <- sprintf("19700101-000000-%08x", seq_along(ids)) | ||
names(replacements) <- ids | ||
function(x) stringr::str_replace_all(x, replacements) |
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.
Why do we need to use stringr for this?
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.
sub/gsub only perform a single substitution, where as we need to do many. I suppose I could compose calls and make one per replacement, but that's annoying to do in a general way. This was just easier.
|
72ef3cb
to
4593902
Compare
The new `orderly_compare_packets` function takes in two packet IDs and produces a diff of the two packets' contents. This includes a comparison of both the packets' metadata and of their files. The actual diff of the files is computed using the diffobj package. A parameter of the function can be used to control which components of the packets are considered in the comparison, and take be one of "everything", "metadata", "files" and "artefacts". This feature was requested as part of the epireview project, where one report's implementation got very messy and needs refactoring, but in the absence of any way of comparing two runs of the same report it is difficult to determine whether the refactor has any unexpected effect on the output.
- Replace the hack of returning TRUE with a class and instead return an R6 class with a `is_equal` method. - Don't print file diff by default, use a `verbose` flag to `print`.
04935e3
to
a3b6352
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #147 +/- ##
==========================================
- Coverage 99.51% 99.26% -0.25%
==========================================
Files 41 42 +1
Lines 3716 3957 +241
==========================================
+ Hits 3698 3928 +230
- Misses 18 29 +11 ☔ View full report in Codecov by Sentry. |
a3b6352
to
7fb4a31
Compare
I think I’m mostly happy with the API now, except for the The rendered output is a bit rough, especially when it comes to viewing the orderly specific metadata, but we can refine that over time. |
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've given this a quick whirl and I think this will be fun to try out today. I'll let people know it's subject to change but the overall idea is now pretty solid I think. Agree that handling of verbose
is a bit gross, and will have a think about what we can do with that
The new
orderly_compare_packets
function takes in two packet IDs and produces a diff of the two packets' contents. This includes a comparison of both the packets' metadata and of their files. The actual diff of the files is computed using the diffobj package.A parameter of the function can be used to control which components of the packets are considered in the comparison, and take be one of "everything", "metadata", "files" and "artefacts".
This feature was requested as part of the epireview project, where one report's implementation got very messy and needs refactoring, but in the absence of any way of comparing two runs of the same report it is difficult to determine whether the refactor has any unexpected effect on the output.