fix either feature conditional compilation, again#3834
fix either feature conditional compilation, again#3834davidhewitt merged 7 commits intoPyO3:mainfrom
either feature conditional compilation, again#3834Conversation
|
For what it's worth, I didn't fancy adding a test for this feature combination in CI, as testing the full set of all combinations of features seems impractical 😢 |
CodSpeed Performance ReportMerging #3834 will not alter performanceComparing Summary
|
adamreichold
left a comment
adamreichold
left a comment
There was a problem hiding this comment.
I wonder how this go through CI, don't we test a lot of feature combinations? I think this tells us that we need at least one more which does not include the experiment-inspect feature.
Sorry for missing that. I also don't we should test the full power set. But I would rather drop a combination that includes the experiment feature than not testing stable features without the experimental bit enabled. |
|
Not sure what you guys are using right now, but we use https://github.com/taiki-e/cargo-hack in our workspace. We don't do powersets, because we often have conflicting feature, but we test each feature individually. I believe that would've been enough to catch this. |
|
I don't think testing all features individually is reasonable for PyO3 because we have many integration features like |
|
👍 (I'll try to get to this tomorrow or over the weekend.) |
davidhewitt
force-pushed
the
either-type
branch
2 times, most recently
from
670678b to
17d6bec
Compare
|
I decided to go for a combination of both; I used the |
| test-feature-powerset: | ||
| needs: [fmt] | ||
| if: ${{ contains(github.event.pull_request.labels.*.name, 'CI-build-full') || (github.event_name != 'pull_request' && github.ref != 'refs/heads/main') }} | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
We could maybe extend to run this for each OS, but my expectation is that there's unlikely to be platform differences caught out by testing specific feature combinations. It seemed wasteful.
Similarly, if running a full test is too slow, we could downgrade to a check.
There was a problem hiding this comment.
Similarly, if running a full test is too slow, we could downgrade to a check.
I think I'd prefer to start with a simple compile check instead of full test build. (The runtime is also where more platform-specific behaviour could lurk, and hence I'd say that single-platform-compile-check is a more natural working point.)
davidhewitt
force-pushed
the
either-type
branch
from
17d6bec to
e7e49c1
Compare
|
That's what we do for our CI (though it is hard to compare library vs binary). We run all tests with no features enabled & all features enabled (Mac once a day, Linux every time, no Windows). Then we use cargo-hack to run check/clippy for all features one-by-one, but no powerset (that probably makes sense for a library though). |
|
The "powerset" I added here has just got three "groups" if you like - |
|
Ufff I missed installing |
adamreichold
left a comment
adamreichold
left a comment
There was a problem hiding this comment.
LGTM now. Only open question is whether to downgrade this to check builds (which I would prefer, but not strongly enough to further delay this).
|
Let's just go for |
|
Thanks for the rounds of review here! I will get on with preparing that patch release once this merges. |
* fix `either` feature conditional compilation, again * test feature powerset in CI * install `rust-src` for feature powerset tests * review: adamreichold feedback * Fix one more case of redundant imports. * just check feature powerset for now --------- Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
* fix `either` feature conditional compilation, again * test feature powerset in CI * install `rust-src` for feature powerset tests * review: adamreichold feedback * Fix one more case of redundant imports. * just check feature powerset for now --------- Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3 participants
#3722 (comment), thanks for reporting @utkarshgupta137