-
Notifications
You must be signed in to change notification settings - Fork 74
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 platform_allowlist for migrator #1655
Conversation
4010042
to
066db69
Compare
066db69
to
c846bf3
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #1655 +/- ##
==========================================
- Coverage 64.42% 64.42% -0.01%
==========================================
Files 88 88
Lines 7901 7912 +11
==========================================
+ Hits 5090 5097 +7
- Misses 2811 2815 +4
... and 9 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Thank you so much! From the name "platform_restriction" I cannot tell if the list is platforms to skip or platforms to keep. Can we think of another name? |
In terms of tests, writing them for this part of the bot is next to impossible. |
Happy to bikeshed, not attached to any particular name. For me, "filter" can be both a positive (e.g. air filter) or a negative (e.g. dust filter), so I tried to avoid it. I guess I pictured "restrict to platform" and not "restricted platform", so didn't notice it's also ambivalent. Maybe |
Yes sorry to nitpick. Platform allow list is perfect. |
Could we not have a micro-version of conda-forge (say 10-20 packages), for which we parse the feedstocks, construct a graph, execute migrations, etc? |
Yep. That's the way to do them. We've been thinking of doing that for a while but it's a lot of work and covering all cases the bot encounters is not trivial. |
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 support both _
and -
in both names in the feedstock data and the migrator data.
Once that works, LGTM.
Migrator side is fine, but not sure what you mean by supporting it in feedstock data. The parser doesn't collect the arches from the meta.yaml directly and uses just one style - AFAICT it needs to use underscores because it constructs keys from it like |
I mean the migrator side only. Sorry for being confusing. |
Very specifically for conda-forge/conda-forge-pinning-feedstock#1359, though hopefully useful in general.
I thought about this a bit, but I'm completely new to this codebase, and it's a bit hard to penetrate TBH. I mainly tried to follow Matthew's idea.
The migrator for fortran-only-on-windows would then look like:
The underscore in
win_64
comes from the same pattern elsewhere infeedstock_parser.py
, but unsurprisingly I don't care whether it's-
or_
(or whatever).The tricker bit is writing tests for this. I tried to look for tests for the similar
wait_for_migrators
, but this has no tests either (which is probably why it's broken)... Advice & help welcome