What is the issue?

Attempts to address https://github.com/meltano/edk/issues/264
There was a change to the EDK that allows interrupt signals to be sent to subprocesses. https://github.com/meltano/edk/pull/75
However when packages begin using this code (in particular dbt-ext at v0.2.0), any development effort on Windows machine stopped working
https://docs.python.org/3/library/asyncio-platforms.html

What was changed?

At first I was trying to figure out how to implement the fix for windows: signal.raise_signal(signal.SIGINT) via https://stackoverflow.com/questions/35772001/how-to-handle-a-signal-sigint-on-a-windows-os-machine/72637975#72637975. The trick is that we are dealing with sub-processes here. My Python knowledge is limited at this time since Windows can't use add_signal_handler - I wasn't quite sure how to best go this way to have the subprocess use it.
Another possible option instead is to not invoke the add_signal_handler during local Windows development - which is what this PR is trying to do.

Example

1) Attempting to run development in Windows with loop.add_signal_handler

2) == to != for win32 check

3) Checking KeyboardInterrupt works

Other notes

We may also be able to set an event loop policy around if the platform we are running on is in Windows - before we get the event loop afterwards. However like I mentioned above my Python knowledge is limited, especially with how async/event loops are managed. I don't think it's a good idea to introduce it but I did want to mention I took a look anyways.

        # If running in windows, set event loop policy instead
        if sys.platform == 'win32':
            asyncio.set_event_loop_policy(asyncio.WindowsProactorEventLoopPolicy())
            loop = asyncio.ProactorEventLoop()
            asyncio.set_event_loop(loop)

📚 Documentation preview 📚: https://meltano-edk--274.org.readthedocs.build/en/274/

meltano / edk

fix: If running in Windows, do not use add_signal_handler() #274

What is the issue?

What was changed?

Example

Other notes