What happened?

Description

Salt's packages bundle a "onedir" build of Python that is separate from whatever Python (if any) is installed on the target system. Today there's no built-in way to run a snippet of Python code or a Python script using that specific interpreter — cmd.run/cmd.script will happily execute python/python3, but which interpreter that resolves to depends entirely on the system's PATH.

This request adds a new execution module, python, with:

• python.run — run a snippet of Python code (-c) or raw interpreter arguments (e.g. -m module), using the exact same Python interpreter (sys.executable) that is running the Salt minion/master.
• python.script — download a Python script (via cp.cache_file/cp.get_template, same flow as cmd.script) and execute it with that same interpreter, rather than relying on the script's shebang line, executable bit, or PATH.

And a paired state module, python, with run and script states mirroring cmd.run/cmd.script's conventions, so this can be used declaratively in SLS files.

Motivation

Onedir packaging means the Python actually executing Salt code is often not the same interpreter a user would get from python3 on PATH. Being able to target Salt's own interpreter directly is useful for automation that needs to guarantee consistent Python behavior/version regardless of what's installed on the system.

Proposed API

salt '' python.run command="print('hello world')"
salt '' python.run args="-m json.tool foo.json"
salt '*' python.script salt://scripts/runme.py 'arg1 arg2'

write-marker-file:
python.run:
- name: open('/tmp/salt-marker', 'w').close()

run-my-script:
python.script:
- source: salt://scripts/runme.py
- args: arg1 arg2

Type of salt install

Official deb

Major version

3007.x

What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)

almalinux-8

salt --versions-report output

3009