Skip to content

Version updates in travis - #648

Closed
bsipocz wants to merge 3 commits into
astropy:masterfrom
bsipocz:travis_update_numpy_II
Closed

bsipocz wants to merge 3 commits into
astropy:masterfrom
bsipocz:travis_update_numpy_II

Conversation

@bsipocz

@bsipocz bsipocz commented Jan 25, 2017

Copy link
Copy Markdown
Member

We've recently found the probably reason of the halting numpy prerelease builds and made a fix in ci-helpers. So I'm removing it from the allowed failures with the note that since there is no prerelease available at the moment it will pass anyway. I'm almost certain that it should work (the fix worked for e.g. photutils).

But while I was already editing the file, also added the new py 3.6 version to the matrix as well as numpy 1.11.

@bsipocz
bsipocz force-pushed the travis_update_numpy_II branch from 35f0105 to 8118326 Compare January 26, 2017 13:20
@aphearin

Copy link
Copy Markdown
Contributor

These failures a sort of mysterious to me, @bsipocz. The latest build has a new round of failures related to the escape sequence \o used in some docstrings.

@bsipocz

bsipocz commented Jan 26, 2017

Copy link
Copy Markdown
Member Author

Yes, those needed to be fixed in astropy and astroquery, too. Too bad I don't yet have py3.6 locally, so can only test it on travis.
The more puzzling issue (that I also see here astropy/astroquery#815) that using unittest seems to trigger a deprecation warning in pytest that it not yet fixed upstream. There are several cases of that here in halotools.

@aphearin

Copy link
Copy Markdown
Contributor

@bsipocz - I just took another look at this PR in light of #664. It looks like 3.6 compatibility requires including an r in front of any triple-quote docstring enclosing an equation. Do I understand that correctly? If so, do you know whether there are automated tools for this? Doing that manually would be onerous in the extreme :-\

@bsipocz

bsipocz commented Feb 19, 2017

Copy link
Copy Markdown
Member Author

@aphearin - Yes, there was a change with escape sequences, and py3.6 got a bit stricter, so we need to have raw strings in many cases (e.g with equations). Unfortunatelly don't know a tool to do this automatically (as one may need to change the docstrings themselves, too).
Anyway I can come back to this later next week again.

@aphearin

Copy link
Copy Markdown
Contributor

Well, that's a bit of a bummer.

FYI, my current release cycle is to try and get v0.5 out within the next couple of weeks, as I have several new features in the master branch that people seem to be using. I expect that v0.6 will not come until the fall, and I am perfectly fine postponing 3.6 compatibility until then. I don't want to stick you with this nuisance of a manual task either - I'm happy to just keep an open PR for a while that I periodically iterate on and rebase as needed.

@bsipocz

bsipocz commented Feb 19, 2017

Copy link
Copy Markdown
Member Author

@aphearin - OK, if you are happy with that let's keep this open. Don't worry, I sometimes need menial tasks to fall back on so I'll update this from time to time.

@aphearin

Copy link
Copy Markdown
Contributor

Same here. In order for me to help chip away at this, is the easiest thing for me to just submit PRs against this branch in your fork?

@bsipocz

bsipocz commented Feb 19, 2017 •

Copy link
Copy Markdown
Member Author

No need for PRs, you can push commits to this branch directly (as a maintainer).

@bsipocz
bsipocz force-pushed the travis_update_numpy_II branch from 8118326 to 994f60a Compare February 19, 2017 18:30
@bsipocz
bsipocz force-pushed the travis_update_numpy_II branch from 994f60a to 5da1d1f Compare March 21, 2017 00:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants