-
Notifications
You must be signed in to change notification settings - Fork 661
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
CI: add 32-bit Win to CI #2696
CI: add 32-bit Win to CI #2696
Conversation
Ok, it is running now. I tried to delete the spurious/duplicate |
* changes needed to pass full test suite on 32-bit Windows * primarily, use `np.intp` indexing types in appropriate locations instead of forcing `np.int64`
@lilyminium @richardjgowers I pushed in a commit that allows 32-bit Windows and 64-bit Linux test suites to pass locally. We'll see if the CI agrees, but you'll probably want to review carefully anyway. In short, mostly |
@@ -398,6 +398,8 @@ class TestNotWithin(object): | |||
def u(): | |||
return mda.Universe(GRO) | |||
|
|||
@pytest.mark.skipif(sys.maxsize <= 2**32, | |||
reason="non-kdtree density too large for 32-bit") |
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.
memory allocation issue specifically, I think
@@ -55,7 +55,7 @@ def test_moltypes(self, top): | |||
def test_molnums(self, top): | |||
molnums = top.molnums.values | |||
assert_equal(molnums, self.ref_molnums) | |||
assert molnums.dtype == np.int64 | |||
assert molnums.dtype == np.intp |
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.
While nobody likes changing unit tests to make them pass, I think the proposed approach (from Richard and maybe Lily?) for portability is that integer indexing will now be platform-sized rather than coerced to int64
, so some tests will have platform-specific typing.
There's only 1 32-bit test failure left in Azure CI--it is an unreliable failure according to |
Ok this is cool. So the one failure is something string related that hypothesis found. Can we tag this from pytest is a knownfail with win32 platforms then we can include this in our test matrix? |
* we now conditionally `xfail` a test that is problematic on 32-bit Windows: `MDAnalysisTests/formats/test_libdcd.py::test_written_remarks_property` * `hypothesis` only occasionally produces a failure for this test on 32-bit Windows
@richardjgowers Ok, I added a third commit to |
Codecov Report
@@ Coverage Diff @@
## develop #2696 +/- ##
==========================================
Coverage ? 91.15%
==========================================
Files ? 175
Lines ? 23719
Branches ? 3104
==========================================
Hits ? 21620
Misses ? 1480
Partials ? 619
Continue to review full report at Codecov.
|
@@ -73,6 +73,8 @@ def test_relative(self): | |||
fixed = check_and_fix_long_filename(abspath) | |||
assert fixed == self.filename | |||
|
|||
@pytest.mark.skipif(os.name == 'nt' and sys.maxsize <= 2**32, | |||
reason="FileNotFoundError on Win 32-bit") | |||
def test_symlink_dir(self, tmpdir): |
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.
Was this also because of not having symlinking privileges, or is it some weirdness with Windows paths and os.path.join
?
(Just out of interest; I'm not sure hole2 even supports Windows.)
package/MDAnalysis/core/selection.py
Outdated
@@ -226,7 +226,7 @@ class ByResSelection(UnarySelection): | |||
|
|||
def apply(self, group): | |||
res = self.sel.apply(group) | |||
unique_res = unique_int_1d(res.resindices.astype(np.int64)) | |||
unique_res = unique_int_1d(res.resindices.astype(np.intp)) |
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.
Is this astype
necessary? I think it required coercion earlier as resindices
are intp
typically.
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 pushed in a commit to remove it--32-bit Windows suite passed locally without it. I didn't have time to run the suite for 64-bit linux as well, but fingers crossed.
Thanks @tylerjereddy! This looks great. I don't know much about win32 but only 5 xfails seems really good; I suppose the non-kdtree densities could have warnings, same with the symlinking (I guess symlinking privileges would be a Windows-wide issue?). |
* remove an extraneous type coercion in `selection.py` based on reviewer feedback
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.
Thank you @tylerjereddy!
Great work, @tylerjereddy ! |
Are we now in a position to officially support 32-bit Windows? Should there be something in CHANGELOG? |
We could add something--I don't know if I'd go as far as "official support," but pretty close. |
FWIW, I'd suggest not using a single plain text changelog for entries since it can be a source of merge conflicts. A simple wiki page in between releases can work well enough. Some projects use fancy tools to add separate notes that get merged later or whatever. Anyway, I'll try to push something in shortly. |
Ok, I've pushed in a changelog entry--I put the recent change at top, but not my name at top--mostly to avoid reformatting the author list, but also technically I've made other changes for the release already without recording the name so that's my excuse. |
Alright, CI is green, 2 core dev approvals and I added a short release note, so merging |
It is true that most merge conflicts come from our custom to add new changes at the top of each category. Maybe it would be better to add at the bottom.
However, I don't like using a Wiki because then we need to check something separately when reviewing PRs, much better to have everything in one place, especially with new contributors.
Yes, I've seen these. Is it worth the extra work? |
Supersedes #2695
Add 32-bit Windows testing via Azure CI (not Appveyor because of the lack of parallel jobs there)
It is up to the team if we want to just place fixes in this PR before merging, switch to "allowed failure" somehow, or just merge in when ready and have "red CI" for a bit until the issues are fixed/skipped/xfailed, etc.
this is a pared-down version of the 32-bit Windows testing I set up for NumPy/SciPy--probably could pare it down even more, but seems to catch the test failures we'd expect
Related to:
#2693
#2687
#2689
#2346