GitHub user cookesan added a comment to the discussion: Edge3 on Windows
That COTS constraint is the important part. I would keep the Airflow/Edge runtime boundary on the Linux side first, then make the Windows-only tool a narrow task boundary. Microsoft documents WSL running Windows `.exe` tools from the Linux command line: https://learn.microsoft.com/en-us/windows/wsl/filesystems#run-windows-tools-from-linux The useful smoke test is whether your exact vendor CLI behaves correctly there, not whether native Windows is a supported Airflow worker target. The current Edge3 docs still treat native Windows worker support as experimental/proof-of-concept and not current for Airflow 3, but the example DAG shape is useful: a dedicated `windows` queue and a small operator that shells out to one Windows process. If the vendor tool needs GUI/session/licensing state, I would move that into a Windows-side wrapper script or service and have the Airflow task call that wrapper. The first test I would run is: can the Linux/WSL Edge worker invoke this vendor tool repeatably with the right identity, paths, exit code, and output artifacts? GitHub link: https://github.com/apache/airflow/discussions/65315#discussioncomment-16659608 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
