release: 0.14.5 #1851
Merged
release: 0.14.5 #1851
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
PyOxidizer will want to create interpreter config files. Rather than reinvent the logic for reading/writing these files, I think it makes sense to consume the `pyo3-build-config` crate so we can use the `InterpreterConfig` type directly. But the symbol needs to be public to allow us to do that. And in order to allow direct construction, we need to make all the types referenced by its fields public as well.
PyOxidizer needs to do some... questionable things with regards to configuring how the Python interpreter is linked. The way I solved this problem for the `cpython` / `python3-sys` crates was by adding a bunch of crate features to control what `cargo:` lines were emitted by the build scripts. This added a lot of complexity to the those crates for a target audience of ~1. Now that PyO3 has support for config files to control settings, this provides a richer mechanism than crate features to influence the build script. This commit defines a new field on the `InterpreterConfig` struct to hold an arbitrary list of strings/lines that should be emitted by the build script. This field is only every populated when parsing config files and it is only read by pyo3's build script to `println!()` additional values. My intended use case for this is to have PyOxidizer effectively control the interpreter link settings via the config file (at my own peril) while having minimal impact on the maintainability of PyO3's code base. Given the complexity of the link hacks employed, you probably don't want this polluting pyo3's code base.
PyOxidizer requires advanced control over the settings used to link libpython. We recently implemented support for configuration files defining explicit lines to emit from build scripts to give callers control over what lines to emit from build scripts so use cases like PyOxidizer's are feasible without hacks in PyO3's code base. However, the default logic in `emit_link_config()` may not be appropriate in scenarios where link settings are provided via this "extra lines" mechanism. The default logic may prohibit use of or interfere with desired settings provided externally. This commit defines a new field on the interpreter config that suppresses the emission of the default link control logic from the `pyo3` build script. It effectively gives advanced consumers like PyOxidizer full control over link logic while minimally polluting PyO3's build logic. I thought about implementing this control as a crate feature. But given the expected target audience size of ~1, I thought a crate feature was too visible for a power user feature and decided to implement it via the configuration file.
This isn't strictly necessary since you can `.0.clone()`. But it is more ergonomic.
davidhewitt
force-pushed
the
release-0.14.5
branch
from
9dd16a8
to
c801dad
Compare
|
Also picked #1853 for PyOxidizer, and based on indygreg/PyOxidizer#433 (comment) there is one final patch we can expect to cherry-pick to complete the 0.14 release series for PyOxidizer. |
2 tasks
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
force-pushed
the
release-0.14.5
branch
from
c801dad
to
c3796c4
Compare
|
Also picked #1856 I think we're probably ready to release this all now... |
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.
davidhewitt
force-pushed
the
release-0.14.5
branch
from
c3796c4
to
f1bb688
Compare
|
... and #1859 . |
|
Release is live! |
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.
This cherry-picks #1793, #1848, and #1850 for the 0.14 series.
As well as releasing the fix for the fedora packaging issue on s390x (#1824), my hope is that PyOxidizer will be able to use this release. cc @indygreg it'd be great if you're able to test PyOxidizer against this branch!
I propose I put this live on Sunday.