DS9 tests fail if DS9 not running in some configurations

XMLWordPrintable

Details

• Type: Bug
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
1
• Epic Link:
• Sprint:
Science Pipelines DM-S15-5, Science Pipelines DM-S15-6
• Team:
Data Release Production

Description

There are a few issues with the robustness of the testDs9.py tests in AFW.

• The tests are skipped if the display_ds9 package can not be loaded but they should also skip if ds9 is missing or if ds9 can not be loaded. The latter is especially important during builds that unset $DISPLAY. • The launching code in initDS9 can not notice the simple case of ds9 immediately failing to load. It simply assumes that there are delays in launch. The reason for this is that os.system does not return bad status if the command has been started in the background. Another scheme for starting ds9 should be considered. Maybe a different exception could be raised specifically for failing to start it. • At the moment each test independently has a go at starting ds9. This makes the tests take a very long time (made worse by _mtv also trying multiple times) despite it being clear pretty quickly that ds9 is never going to work. • Currently the mtv tests must run early as they are the only tests that attempt to start ds9 if it is not running. If the two tests that call mtv are disabled two other tests fail. Ideally the initDS9 code should be called in all cases. Attachments Activity Hide John Swinbank added a comment - Sounds like this is causing Tim Jenness some issues; let's try and get it resolved in the current sprint. Show John Swinbank added a comment - Sounds like this is causing Tim Jenness some issues; let's try and get it resolved in the current sprint. Hide Robert Lupton added a comment - I've pushed changes to afw and display_ds9 (both on tickets/DM-2390) that may make you happy. Specifically, I check if ds9 is on the path and$DISPLAY is set before attempting to exec ds9,
and I check at the top of testDS9.py to see if ds9 is functional.

I still try the exec many times if I think it'll eventually work – that code was written long ago to work on slow X connections and I'm loath to fiddle with it now.

Show
Robert Lupton added a comment - I've pushed changes to afw and display_ds9 (both on tickets/ DM-2390 ) that may make you happy. Specifically, I check if ds9 is on the path and \$DISPLAY is set before attempting to exec ds9, and I check at the top of testDS9.py to see if ds9 is functional. I still try the exec many times if I think it'll eventually work – that code was written long ago to work on slow X connections and I'm loath to fiddle with it now.
Hide
Tim Jenness added a comment -

This solves the immediate issue of not retrying multiple times when the command is not ever going to work and also solves the problem of order of test execution affecting the outcome of the tests. Thank you.

Show
Tim Jenness added a comment - This solves the immediate issue of not retrying multiple times when the command is not ever going to work and also solves the problem of order of test execution affecting the outcome of the tests. Thank you.
Hide
Robert Lupton added a comment -

Merged but I forgot to close the issue.

Show
Robert Lupton added a comment - Merged but I forgot to close the issue.

People

• Assignee:
Robert Lupton
Reporter:
Tim Jenness
Reviewers:
Tim Jenness
Watchers:
John Swinbank, Robert Lupton, Tim Jenness
• Votes:
0 Vote for this issue
Watchers:
3 Start watching this issue

Dates

• Created:
Updated:
Resolved: