Failing vary_perf/wfc3_binned_asn/* tests in dev about drizzlepac

[mcara]

@pllim "It is a known issue" 😄 It is the result of the fix in #86 for integer division. I am working on other tweakreg fixes (#87) and I will just OKify these tests once I am done.

[mcara]

Fixed via spacetelescope/stsci.skypac#16 The problem was in stsci.skypac.

[mcara]

@drdavella Any ideas?

[drdavella]

Sorry, this got lost in my email. If you can tell me how to reproduce this, I'll look into it.

[mcara]

Unfortunately, @pllim @jhunkeler , the way new Python 3.5 tests have been set up, they overwrite 2.7 tests (both tests run in the same directory even though I suggested in a different issue that such practice be discontinued). So, I will have to set-up exact environment as on Sept. 25th and see if I can reproduce the error and possibly get more details on this error.

[pllim]

@mcara , we stopped testing in Python 2 -- That won't even work with astropy dev anymore. Not sure what is the problem here regarding PY2/PY3. If you can see this failure in Python 3, just go from there.

[pllim]

Rule of thumb -- Anything that deals with astropy>=3 (this includes the PR you mentioned above), don't use Python 2 anymore.

[mcara]

@pllim I still need to understand why did these tests failed with a weird message regarding binary/write file open mode.

[drdavella]

Here's an outline of the problem: in addition to filenames, URLs, etc., fits.open allows you to pass open file handles. For example:

with open('example.fits', 'rb') as handle:
    ff = fits.open(handle)

Since FITS is a binary file format, it only makes sense to pass file handles that were opened with mode='rb', mode='wb', or similar. Passing a file that was opened in text mode does not make sense. However, io.fits was previously not checking for that condition in all cases.

I looked through the drizzlepac source and it was not immediately apparent to me that there were any cases where a file handle was being passed to fits.open. As far as I could tell, in all cases a file name was being passed.

So I'm not exactly sure where this error is coming from on your end, but if there is a way to reproduce it, I'm happy to help track it down.

[pllim]

I don't see that failure today. Do you? https://ssb.stsci.edu/pandokia/pandokia.cgi?query=treewalk&host=%25&project=drizzlepac&test_run=conda-conda_tests_py3_2017-09-29-09%3A44%3A02

[mcara]

I do not see this error in Python 3 tests but this does not mean that there is no problem with the code. In particular, if drizzlepac code (in fact I suspect it is drizzlepac & skypac) was mixing opening modes as described by @drdavella - maybe we should fix this anyway. Why the pass now - I have no idea - I definitely did not make any commits to neither drizzlepac nor skypac recently...

@drdavella All the tests that were failing were run in the "inmemory" mode when most of the images are kept in memory and not written out to the disk. I will need to see if there is some sort of conflict there but it is weird that now in Python 3 these tests are OK...

[pllim]

While WFC3 test passes now, the ACS one is failing -- https://ssb.stsci.edu/pandokia/pandokia.cgi?query=detail&key_id=115937021

[mcara]

@pllim Actually, I need to clarify my previous comment: pixsky1 test is failing because acs_tweak was OKified earlier. These two tests are in tandem and pixsky1 depends on the results of the first one. When I OKify the first test this second test starts failing next day.

I have just OKified this test to have all tests clear for upcoming merges.

[pllim]

Thanks, @mcara . drizzlepac appears to be passing nicely now. (Hides back in shadow.)

[pllim]

utils!!!