pyo3-build-config: add a crate feature to control build script #1856
Conversation
This file contains 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
I have a use case in PyOxidizer where I want to use the pyo3-build-config crate as a library crate so I can access the `InterpreterConfig` struct so I can read/write config files without reinventing the wheel. This is doable before this commit. But it requires that the build environment have a Python interpreter. This is undesirable for library usage. This commit introduces a cargo feature flag to control whether the build script does anything. The feature flag must be present for the build script to resolve a config. The feature flag is enabled by default for backwards compatibility. The pyo3 and pyo3-macros-backend crates use this feature by default, for backwards compatibility and because it is the reasonable default. This is probably room to conditionalize some APIs and other behavior based on this feature flag. But we stop short of doing that for the time being.
davidhewitt
approved these changes
Sep 2, 2021
There was a problem hiding this comment.
👍 as discussed on indygreg/PyOxidizer#433 I think this makes sense to enable programmatic use case of pyo3-build-config!
Merged
indygreg
added a commit
to indygreg/pyo3
that referenced
this pull request
Sep 3, 2021
PR PyO3#1856 was buggy in that the `pyo3-build-config` crate didn't actually work in library mode because `include_str!()` was attempting to resolve missing files as part of populating some `const` values. We could change the logic of these constants to make them lazy if we wanted to support possibly getting access to the value. But the simple solution is to conditionalize their presence on the crate feature. Test coverage for building and testing the crate in insolation with the feature disabled has been added. Various code has been conditionalized to avoid compiler warnings. Also, it appears `cargo build|test -p pyo3-build-config --no-default-features` still passes default features. This seems wrong to me. But it is how my system behaves. Maybe it is an sccache bug? I coded the new tests to `cd pyo3-build-config` first to work around.
indygreg
added a commit
to indygreg/pyo3
that referenced
this pull request
Sep 3, 2021
PR PyO3#1856 was buggy in that the `pyo3-build-config` crate didn't actually work in library mode because `include_str!()` was attempting to resolve missing files as part of populating some `const` values. We could change the logic of these constants to make them lazy if we wanted to support possibly getting access to the value. But the simple solution is to conditionalize their presence on the crate feature. Test coverage for building and testing the crate in insolation with the feature disabled has been added. Various code has been conditionalized to avoid compiler warnings. Also, it appears `cargo build|test -p pyo3-build-config --no-default-features` still passes default features. This seems wrong to me. But it is how my system behaves. Maybe it is an sccache bug? I coded the new tests to `cd pyo3-build-config` first to work around.
indygreg
added a commit
to indygreg/pyo3
that referenced
this pull request
Sep 3, 2021
PR PyO3#1856 was buggy in that the `pyo3-build-config` crate didn't actually work in library mode because `include_str!()` was attempting to resolve missing files as part of populating some `const` values. We could change the logic of these constants to make them lazy if we wanted to support possibly getting access to the value. But the simple solution is to conditionalize their presence on the crate feature. Test coverage for building and testing the crate in insolation with the feature disabled has been added. Various code has been conditionalized to avoid compiler warnings. Also, it appears `cargo build|test -p pyo3-build-config --no-default-features` still passes default features. This seems wrong to me. But it is how my system behaves. Maybe it is an sccache bug? I coded the new tests to `cd pyo3-build-config` first to work around.
davidhewitt
pushed a commit
that referenced
this pull request
Sep 3, 2021
PR #1856 was buggy in that the `pyo3-build-config` crate didn't actually work in library mode because `include_str!()` was attempting to resolve missing files as part of populating some `const` values. We could change the logic of these constants to make them lazy if we wanted to support possibly getting access to the value. But the simple solution is to conditionalize their presence on the crate feature. Test coverage for building and testing the crate in insolation with the feature disabled has been added. Various code has been conditionalized to avoid compiler warnings. Also, it appears `cargo build|test -p pyo3-build-config --no-default-features` still passes default features. This seems wrong to me. But it is how my system behaves. Maybe it is an sccache bug? I coded the new tests to `cd pyo3-build-config` first to work around.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I have a use case in PyOxidizer where I want to use the
pyo3-build-config crate as a library crate so I can access the
InterpreterConfigstruct so I can read/write config files withoutreinventing the wheel.
This is doable before this commit. But it requires that the
build environment have a Python interpreter. This is undesirable
for library usage.
This commit introduces a cargo feature flag to control whether the
build script does anything. The feature flag must be present for
the build script to resolve a config. The feature flag is enabled
by default for backwards compatibility. The pyo3 and pyo3-macros-backend
crates use this feature by default, for backwards compatibility and
because it is the reasonable default.
This is probably room to conditionalize some APIs and other behavior
based on this feature flag. But we stop short of doing that for
the time being.