grass.script.setup: Run the presumably failing first call internally

[wenzeslaus]

Based on reports in #5906, #4480, and elsewhere, the first subprocess call to C tool fails, but the second one succeeds, so let's do the first call during the setup.

This is more an exepriment, than a proposed change, but if it works...

[wenzeslaus]

The env changes are now in #5920. I take suggestions on what to enable in CI to get the "execute first to fail" change tested here, e.g., which tests to enable.

[echoix]

Add pytest-randomly plugin on Windows (through pip instal ...), and run multiple times. It will shuffle order

You could also duplicate the step that runs pytest, make it continue-on-error, and inside the same step do the cleanup so the gisrc would be cleared between iterations.

Also, to speed up, set to stop on first failure like: https://docs.pytest.org/en/latest/how-to/failures.html#stopping-after-the-first-or-n-failures

You would have multiple tries in a same run.

[echoix]

These were missing the shell: instruction, so didn't run.

Maybe since I didn't see anything to clear the GISRC or the hypothesis on what was the one-time change that made the rest work, only the first iteration we can conclude.

[wenzeslaus]

The first two actually had shell. Now all of them do.

I actually wanted to follow up on the GISRC. What do you mean by cleaning it? Nothing should remain between the steps.

[wenzeslaus]

From the recent changes, the one which by far is the most likely change to fix OSError: Cannot find the executable g.proj in #4480 (comment) is #5717 which provides the runtime environment in env, namely the PATH, to the shutil.which function. In that context, it is clear that setting up global environment in another test would have resolved the situation (and hide the issue).

I wonder if the theory about the first C executable still holds - in #5906, it was g.region outside of the create_project which failed, but nevertheless it is goes through the same shutil.which function call as g.proj in create_project.

[wenzeslaus]

The g.region issue was actually directly addressed by a different fix: the env is now passed to debug which then runs g.gisenv with existing GISRC (session first) when provided as opposed to failing or working by another session lingering around in os.environ.