These are chat archives for astropy/astropy

20th
Apr 2016
Michael Seifert
@MSeifert04
Apr 20 2016 01:06
@eteq I think I've done a mistake by submitting astropy/astropy#4792 . The module I've loaded is not identical to the one used originally and even though I haven't found a case where it actually enters the edited function (I think that's because embray fixed it upstream: http://bugs.python.org/issue18876) the function itself may give wrong results - because sometimes the used dll differs. Is there a way to unmerge it again? :(
Erik Tollerud
@eteq
Apr 20 2016 02:38
@MSeifert04 - nope, sorry, no way to un-merge per se, because that would be re-writing history. But you certainly can issue a PR to un-do it. git revert might be helpful here (despite the name, it actually creates new commits that undo old ones)
But before doing so... it would be good to know in what circumstances this might go wrong
that is, it appears all the tests on appveyor are passing
But if you think there's a specific problem, adding a regression test would be good (i.e. something that fails because of the change, even if you then have to xfail it)
But we do still want that warning suppressed, right? So is there a way to catch the warning without changing the actual module?
Brigitta Sipocz
@bsipocz
Apr 20 2016 13:54
@eteq - To be honest I did the testing with astroquery, where building the docs doesn't take 10mins.
But: at the moment astropy-helpers supports only py2 docs builds, since astropy/astropy-helpers#216 is not yet merged.
That was tested, and indeed didn't have any remaining warnings coming from the core docs builds both on py2 or py3.
I can test later this evening whether this is still true with sphinx 1.4
Erik Tollerud
@eteq
Apr 20 2016 15:24
Ohhh, right, for some reason I thought all that intersphinx stuff had been merged
yeah, the errors look like exactly what I would think for that, so it’s probably that
would be goo to test astropy/astropy-helpers#216 with 1.4 anyway, though
So is astropy/astropy-helpers#216 ready aside from the question of when to release it, @bsipocz?
(Actually, looks like it needs a rebase… but other than that?)
Brigitta Sipocz
@bsipocz
Apr 20 2016 16:38
Well, I think it can't hurt to release it asap (doesn't broke anything that worked neither changes an API). The release date is I think more a question for the somewhat related astropy/astropy PR (but it shouldn't be merged the same time, it just depends on the helpers one)
Erik Tollerud
@eteq
Apr 20 2016 17:11
Hmm, well I guess I see it as sort of an “API change” in that it changes how sphinx behaves
or at least a “significant behavior change"
just so I’m clear, though - the main difference is that now sphinx builds work on py3, whereas before they only worked on py2, right?
Brigitta Sipocz
@bsipocz
Apr 20 2016 17:13
the difference is even simpler. Previously we provided a local intersphinx for a few failing api references for py2 sphinx builds (e.g. references to python3 features, etc missing from the official python2 inventory). Now we provide it for both py2 and py3, so both work.
so for the user point of view it means no (or less) warnings for py3 builds.
Erik Tollerud
@eteq
Apr 20 2016 17:16
ok, gotcha
but it’s enough of a change that someone might be surprised that it’s a “bugfix”, right? That is, it adds a significant new thing from a dev point of view
put another way: is it possible that it will have unintended consequences like someone did something assuming this wasn’t in, but adding this will break those workaroudns
(I’m asking this mostly out of ignorance as I’ve not looked at these changes in any detail)
Brigitta Sipocz
@bsipocz
Apr 20 2016 17:22
I don't think it will brake any workarounds (but can't guarantee as the number of possible workarounds is always infinite :) ). The easiest workaround was to ignore those missing links by adding them to nitpick-exceptions, and it should work just the same.
Thomas Robitaille
@astrofrog
Apr 20 2016 18:10
I don't see how this could break any backward-compatibility, and it kind of is a fix, so I'm enclined to treat it as a bug fix
Erik Tollerud
@eteq
Apr 20 2016 18:11
ok, you’ve both convinced me ;)
Simon Conseil
@saimn
Apr 20 2016 20:52
Is there no way to tell python setup.py test to not capture the output ? (The -s option of py.test)
Simon Conseil
@saimn
Apr 20 2016 21:04
Oh I missed the -a option, so -a -s works !
Michael Seifert
@MSeifert04
Apr 20 2016 21:21
Hi everyone
I'm currently collecting file-objects that are (sometimes) used as astropy.io.fits.open-arguments (see https://github.com/astropy/astropy/pull/4793#issuecomment-212331171) so if you know of any file-like object that I forgot (and you already used it and it worked) it would be very kind if you could leave a comment there.
Brigitta Sipocz
@bsipocz
Apr 20 2016 21:42
@eteq - I can confirm that astropy/astropy-helpers#216 works with sphinx v1.4+, and core docs build passes on both py2 and py3 (the latter on the rebased branch of astropy/astropy#4556).