And sorry, my IDE cleans up trailing spaces before saving files so there are a few white spaces modifications that are polluting the diff.

If you are finding whitespaces modifications really annoying, you can click the checkbox hide whitespace then click Apply and reload (see below).

Ah, and so the following works since I guess in this case there must be logic in either the Python wrapper for FGFDMExec or within FGFDMExec itself to figure out the path to the JSBSim files relative to it's installed location?

PATH_TO_JSBSIM_FILES=None
fdm = jsbsim.FGFDMExec(PATH_TO_JSBSIM_FILES)

Looks good to merge in. I did test it out in Google Colab to confirm that the PATH_TO_JSBSIM_FILES=None option works.

P.S
I prefer seeing the [skip_ci] label at the end of the line, easier to scan and read.

Green light to merge?

Looks good! Go for it

I prefer seeing the [skip_ci] label at the end of the line, easier to scan and read.

@seanmcleod70 Currently this does not work. The CI workflow is skipped if and only if the commit message (and PR title) starts with [skip ci] (also note that it is using a space and not an underscore).

However this could be modified to use the function contains so that the label could be placed anywhere in the commit message.

Hmm, I was pretty certain that when I looked up [skip ci] a while ago that I saw documentation mentioning that it could appear anywhere in the line.

But doing a quick search on it and looking at documentation from Github:

https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

If any commit message in your push or the HEAD commit of your PR contains the strings [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped.

https://docs.github.com/en/actions/how-tos/manage-workflow-runs/skip-workflow-runs

Workflows that would otherwise be triggered using on: push or on: pull_request won't be triggered if you add any of the following strings to the commit message in a push, or the HEAD commit of a pull request:

I see the Github documentation is ambiguous.

And regular Bing Copilot (as opposed to Copilot Pro 😉) has an example with [skip ci] at the end of the line.

Now having said all that I hadn't looked at jsbsim/.github/workflows/cpp-python-build.yml partly because I thought (without knowing too much about how the CI is setup) that this level of filter checking happened at a higher level by Github before our custom CI build actions were invoked.

Actually reading: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/skip-workflow-runs

If a workflow is skipped due to path filtering, branch filtering or a commit message (see below), then checks associated with that workflow will remain in a "Pending" state. A pull request that requires those checks to be successful will be blocked from merging.

So does that not imply that our workflow cpp-python-build will be skipped and therefore the following is superfluous?

And maybe was only required before 2021 before Github added support?

Just pushed a new commit to #1332 with a trailing [skip ci] and it looks like it didn't kick off the CI workflow.

But doing a quick search on it and looking at documentation from Github:
[…]

I did not know that this feature had been added to GitHub.

The code I mentioned above was added by the commit 7c3d47a on Feb 6, 2021 and the GitHub feature you mentioned was added on Feb 8, 2021, just 2 days after I had implemented some code for [skip ci] so that was a close call; I could have saved myself the trouble of implementing it 😄

Because of that, for more than 4 years I was convinced that the code in cpp-python-build.yml was managing the [skip ci] label and hence that [skip ci] should be put at the beginning of the commit message.

@seanmcleod70 I've just realized that one of your question has remained unanswered.

so the following works since I guess in this case there must be logic in either the Python wrapper for FGFDMExec or within FGFDMExec itself to figure out the path to the JSBSim files relative to it's installed location?

Yes, the logic is in the Python wrapper. When None is passed to the constructor of FGFDMExec, the else branch is taken in the code below and JSBSim root is set to the "default root directory" i.e. the directory where the standard aircraft have been installed by pip.

The function get_default_root_dir scans all the standard directories where the Python packages are installed. It is looking for a directory jsbsim/aircraft in one of these directories and return the corresponding path or raise an exception on failure.