app: Fixes startup issue on newer versions of python (>=3.14)

[tmagik]

This adds to #115 and fixes a startup issue on Debian 13 (and probably recent fedora as well)

[wico-kolmas]

@tridge or @joshanne, could you please have a look at this PR, so that people are able to install the tool again? Thanks a lot!

[joshanne]

Hi @tmagik - thanks for this PR.

I can see at some point after python 3.12.2 and 3.14.x the function get_start_method starts returning forkserver instead of None (at least on my ubuntu machine).

I've tested this change on both, it works as i would expect.

I can try help get this merged as its own changeset, but could you update:

• Rename the PR to something more in line with what you've changed - in this case, fix main from (re)setting the multiprocessing start method.
• Drop the additional commits (I understand you may be using them but they've made your PR dependent on those changes)

This is more of a conditional approval at this stage.
Thanks

[tmagik]

@joshanne It's a lot easier for me to test if one of the importlib/pkg resources changes can get merged (#115 or the approach in #117) let me know which one seems better..

[joshanne]

I'm happy to help get the fix spawn changed for newer versions of python. We'll need to rebase this and drop the pkg_resource changes though.

[joshanne]

Dependent on #115

[joshanne]

@tmagik #115 has now been merged. Could you rebase your branch on top?

[joshanne]

@tmagik i've rebased this on the latest master branch now, dropped the conflicting files and keeping just the fix spawn changes.

[joshanne]

Alright, so this is the difference:

# Python 3.10.12
sys.version='3.10.12 (main, Mar  3 2026, 11:56:32) [GCC 11.4.0]'
multiprocessing.get_start_method(allow_none=True)=None
multiprocessing.get_start_method(True)=None

# Python 3.13.9
sys.version='3.13.9 (main, Oct 28 2025, 12:10:42) [Clang 20.1.4 ]'
multiprocessing.get_start_method(allow_none=True)='fork'
multiprocessing.get_start_method(True)='fork'

Traceback (most recent call last):
  File "/home/USER/Workspace/gui_tool/bin/dronecan_gui_tool", line 60, in <module>
    from dronecan_gui_tool.main import main
  File "/home/USER/Workspace/gui_tool/dronecan_gui_tool/main.py", line 77, in <module>
    multiprocessing.set_start_method('spawn')
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/USER/.local/share/uv/python/cpython-3.13.9-linux-x86_64-gnu/lib/python3.13/multiprocessing/context.py", line 247, in set_start_method
    raise RuntimeError('context has already been set')
RuntimeError: context has already been set

Ignore the line numbers, since I have additional debugging in there - but the error is there - newer versions of python have multiprocessing start method to be fork by default when we get to this point in the application.

I think it may be sufficient to start multiprocessing if it is not set, but if it is set, then continue without attempting to restart it.

@tridge @Huibean do you have any thoughts?

Also need to double check this doesn't break other Operating Systems.

Need to ensure that the behaviour of fork doesn't break anything in the rest of the project that uses threads and assumed spawn.

[tmagik]

Tested on MacOS (arm) and Linux, and everything seems to work correctly.