-
-
Notifications
You must be signed in to change notification settings - Fork 28
Description
Problem
In a managed enterprise Windows environment (e.g. with AppLocker/WDAC), execution of console-script .exe launchers such as robotcode is blocked (“Access denied”). While Python module execution is allowed, RobotCode currently does not provide a supported Python module entry point (e.g. python -m robotcode). As a result, RobotCode has no usable runtime entry point in this environment, even though it is installed and importable.
Observed behavior:
robotcode --help→ Access deniedpython -m robotcode --help→ fails (no module entry point)
By contrast:
python -m robot --helpworks (Robot Framework)python -m pabot.pabot --helpworks (pabot)python -m robocop --helpworks (Robocop)
Requested enhancement
Provide an officially supported Python module entry point for the RobotCode CLI (for example python -m robotcode, or a documented equivalent) that exposes the same functionality as the existing robotcode console script, including RobotCode CLI commands such as robotcode robot or robotcode analyze.
This would allow RobotCode to be used in CI/CD and enterprise environments where executable launchers are restricted, without changing or removing the existing CLI behavior.
Alternatives considered
- Using undocumented internal imports to invoke RobotCode logic directly (fragile and version-dependent).
- Avoiding RobotCode entirely and using python -m robot with argument files, which works but loses RobotCode-specific features such as profiles (robot.toml).
- Relying on console-script .exe launchers, which is not possible in locked-down environments.
Additional context
Other tools in the same ecosystem (Robot Framework, pabot, Robocop) support execution via python -m …, which allows them to run in restricted environments without relying on executables. Providing a similar module entry point for RobotCode would align it with these tools and improve usability in enterprise and CI setups.