SWIG 4.2.0 causes failure in test_bskAttitudeConstrainedManeuver

[dpad]

Describe the bug When SWIG 4.2.0+ is used to build Basilisk, the test-case below fails when run as pytest src/tests -k "scenarioAttitudeConstrainedManeuver":

        coneInOutList.append(vizElement)
>       del viz.settings.coneList[:]  # clear settings list to replace it with updated list
E       TypeError: 'SwigPyObject' object does not support item deletion

../dist3/Basilisk/utilities/vizSupport.py:783: TypeError

tests/test_scenarioAttitudeConstrainedManeuver.py::test_bskAttitudeConstrainedManeuver[False-20-70-0] - TypeError: 'SwigPyObject' object does not support item deletion

This test case passes when Basilisk is built with SWIG 4.0.2 instead.

See my additional comments below, it only occurs under specific circumstances. This bug is probably fairly low priority.

Desktop (please complete the following information):

• OS: Linux (Ubuntu 22.04)
• Version develop (2.3.25)
• Python version 3.10.12

[dpad]

Ok, so this bug is kind of bizarre. It might be due to some global state of some kind.

• pytest src
  • :white_check_mark: Passes all test cases, including this one, on SWIG 4.2.0
  • :white_check_mark: Passes all test cases, including this one, on SWIG 4.0.2.
• pytest src/tests/test_scenarioAttitudeConstrainedManeuver.py
  • ✅ Passes this test case on SWIG 4.2.0
  • :white_check_mark: Passes this test case on SWIG 4.0.2.
• pytest src/tests -k "scenarioAttitudeConstrainedManeuver"
  • ❌ Fails this test case on SWIG 4.2.0
  • :white_check_mark: Passes this test case on SWIG 4.0.2.

[dpad]

I've potentially tracked down the issue to dataFileToViz. Basically, commenting out the from Basilisk.simulation import dataFileToViz in scenarioDataToViz.py allows the pytest src/tests -k "scenarioAttitudeConstrainedManeuver" to pass even with SWIG 4.2.0.

This is a very strange bug, but maybe this helps someone identify the issue.

[sassy-asjp]

This duplicates #632

The bug is actually even more mysterious than at first glance. The bug embeds itself into the python cache, such that in certain scenarios, once you run the test in a way that fails even a way that works will fail until you remove the python cache, and vice versa.

[dpad]

Closing this in favour of #632 , thanks @sassy-asjp !