I think if somebody is building all targets for SCons then we need to always obliterate the previous pytest information.

If somebody is only performing a scons install, then we DO NOT obliterate previous outputs.

Developers type scons repeatedly and so we have to make that work.

I'm not sure what the difference is between "building all targets" and "only performing a scons install", especially for a python-only package.

See the linked ticket DM-11693 – scons always runs the tests, and scons install always runs the tests, so when you use eupspkg to install you run the tests twice unless the second time scons can work out that it doesn't need to.

Let me rephrase that - If a developer explicitly asks to execute a scons install - which is actually rare and something that is mostly executed in CI or in eupspkg install (I think), then we do not clean up previous .failed files. Otherwise, we always clean up .failed files.

A fix would add:

@rm -f ${{TARGET $TARGET.failed;}}

Back into the SCons Command that executes pytest, before running pytest, if there's no install is not in SCons.Script.COMMAND_LINE_TARGETS.

Okay, I see.  That makes sense to me.

I have a fix in, this should obliterate files when you are not performing an install, and preserve the files if you are doing an install

Jenkins job: 28745, passed linux so far, still waiting on Mac.

I tried testing this locally with a test case that fails and it seems to be working as intended.

Tim Jenness I think this should be fixed adequately. I ran a CI 10/12/2018 (job #28844) and it seems to be behaving as normal when running scons directly.

I can confirm that this fixes the problem for me.

Merged.