CI: temporarily remove in-repo Python tests #247
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These tests don't really behave as expected: the code is built using the in-repo python-build-standalone 3.12 interpreter (set by `python.defaultinterpreter`) but is executed under the Python interpreter provided by the runner (set by `python.defaultshebang`; also 3.12 on `ubuntu-latest`). We'll shortly begin work on a .pex preamble format that will allow the use of the python-build-standalone interpreter at both build and run time, at which point this test can be readded.
chrisnovakovic
force-pushed
the
disable-in-repo-python
branch
from
0ed6669 to
51264d0
Compare
toastwaffle
approved these changes
Oct 10, 2025
chrisnovakovic
added a commit
to chrisnovakovic/python-rules
that referenced
this pull request
Dec 1, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in please-build#247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
chrisnovakovic
added a commit
to chrisnovakovic/python-rules
that referenced
this pull request
Dec 1, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in please-build#247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
chrisnovakovic
added a commit
to chrisnovakovic/python-rules
that referenced
this pull request
Dec 1, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in please-build#247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
chrisnovakovic
added a commit
to chrisnovakovic/python-rules
that referenced
this pull request
Dec 3, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in please-build#247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
chrisnovakovic
added a commit
to chrisnovakovic/python-rules
that referenced
this pull request
Dec 3, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in please-build#247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
chrisnovakovic
added a commit
to chrisnovakovic/python-rules
that referenced
this pull request
Dec 3, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in please-build#247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
chrisnovakovic
added a commit
that referenced
this pull request
Dec 3, 2025
There is currently an assumption that the Python interpreter used while building .pex files (i.e. the value of `DefaultInterpreter`) is also the Python interpreter that runs them. This can be overridden with the `shebang` parameter on individual `python_binary` and `python_test` targets, which sets the shebang in the generated .pex file to a specific value. The functionality this provides is limited: - If additional interpreter arguments are specified by the target, the generated .pex file will depend on a shell at `/bin/sh` in the run-time environment (which isn't guaranteed to exist, e.g. in distroless containers), as well as `/usr/bin/env` (also not guaranteed to exist). - It is possible to build the .pex file using a Python interpreter defined as a build target in the repo, but it isn't possible to run the .pex file using that interpreter because the .pex file's shebang is (by definition) static, but the interpreter's path relative to the .pex file's path varies depending on the context (e.g. whether the .pex file exists inside a build environment vs outside of one). This was discussed in #247. Provide more flexibility in how .pex files are run by prepending a native-code preamble that implements dynamic searching of Python interpreters. The behaviour of this preamble is controlled at run time by a special zip member within the .pex file, `.bootstrap/PLZ_PREAMBLE_CONFIG`, which contains a list of candidate paths for Python interpreters under which the .pex file should be executed and a list of arguments to pass to the interpreter when attempting to execute it. The lists can be customised per `python_binary` or `python_test` target via the `runtime_interpreters` and `runtime_interpreter_args` parameters respectively; new plugin configuration options, `DefaultRuntimeInterpreters` and `DefaultRuntimeInterpreterArgs`, provide default values. If both are unspecified, the plugin's current behaviour is maintained (i.e. the same interpreter is used to both build and run the code). The flexibility offered by the new .pex preamble is sufficient to be able to remove `python_binary` and `python_test`'s `shebang` parameter (and the `DefaultShebang` plugin configuration option) altogether. The new .pex preamble is compact enough to prepend to all .pex files in a repo without collectively making them prohibitively large: ~98KB statically linked with musl on Linux, ~83KB dynamically linked on Darwin (which doesn't have a stable kernel ABI, and strongly discourages static linking). Among other possibilities, this allows for the creation of .pex files that are truly portable between run-time environments of the same operating system and architecture - e.g., the preamble can be configured to attempt to execute an interpreter that only exists within a production environment (such as a distroless container with its interpreter at `/python/bin/python3`), falling back on an interpreter defined as a build target in the repo if the .pex file is still located within Please's development/testing environment.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These tests don't really behave as expected: the code is built using the in-repo python-build-standalone 3.12 interpreter (set by
python.defaultinterpreter) but is executed under the Python interpreter provided by the runner (also 3.12 onubuntu-latest).We'll shortly begin work on a .pex preamble format that will allow the use of the python-build-standalone interpreter at both build and run time, at which point this test can be readded.