Add options for handling [extras] dependencies#528
Add options for handling [extras] dependencies#528DilumAluthge merged 11 commits intoJuliaRegistries:masterfrom
[extras] dependencies#528Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #528 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 12 11 -1
Lines 412 411 -1
=========================================
- Hits 412 411 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Could we make this experimental for now? That way, we can try it out, and if we don't like the API, we can change it? |
|
By "experimental", I mean explicitly document that we are allowed to break it in a minor (or even patch) release of CompatHelper. |
|
I added a note. |
Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
|
@DilumAluthge this PR is ready for another round of review 🙂 |
|
@DilumAluthge bump 🙂 |
|
I can try to review this weekend. |
Famous last words, huh? |
DilumAluthge
left a comment
There was a problem hiding this comment.
The code looks good to me.
There's one tweak I'd like to make to the tests (just to restore Baz back to [deps], as it was before this PR). Once that's done, I think this PR is good to merge.
|
@DilumAluthge can you create a new release? |
This PR extends #502 based on @DilumAluthge's suggestions in #502 (comment).
I added an option
open_prs_for_extrasthat can be set toIfExistingCompatExtras()(the default),AllExtras()orNoExtras()[my gut feeling is that the names could be improved a bit]. WithIfExistingCompatExtras(), only[extras]dependencies with existing compat entry are updated; withAllExtras(), all[extras]dependencies are updated (also those without existing compat entry); and withNoExtras(),[extras]dependencies are not updated.I went with singleton types (basically a type-based enum) because 1) it felt more consistent with the existing
EntryTypeand 2) it's not necessary to check whether the provided value is valid (which would be necessary if the API would be based onSymbols).Fixes #166. Closes #502.