Share protobuf runtime and expose optional-wheel build capabilities - #1499
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9e34880b46
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @_lruCache(maxsize=1) | ||
| def _installedBuildFeatureProviders() -> dict[str, tuple[tuple[str, str], ...]]: |
There was a problem hiding this comment.
Refresh providers after environment changes
When a long-running process changes its environment after the first feature query—for example, a notebook runs %pip install bsk-opnav after hasBuildFeature("opNav") returned False—this process-lifetime cache prevents the newly installed entry point from ever being discovered; uninstalling or upgrading a provider similarly leaves stale capabilities or version-mismatch errors. The install/uninstall checks use fresh subprocesses, and the unit test manually clears this cache, so they do not cover the persistent-process behavior. Avoid caching this metadata indefinitely or provide automatic invalidation so the query reflects the currently installed distributions.
Useful? React with 👍 / 👎.
Build protobuf as a shared Conan dependency so OpenCV-backed OpNav and vizInterface bindings use one runtime without crashing at interpreter shutdown. Add subprocess import-order coverage for source builds and optional wheels, and document the resolved issue.
- let optional wheels declare build features through entry-point metadata - preserve core build provenance while detecting installed feature providers - reject optional providers that do not match the core Basilisk version - validate the intentional build-metadata delta used to create extension wheels - test feature discovery, metadata failures, and optional-wheel installation states - document feature guards for monolithic and split-wheel installations
Remove process-lifetime caching from optional build feature discovery so hasBuildFeature() reflects providers installed, upgraded, or removed while Python is running. Add same-process coverage using real distribution metadata and remove obsolete manual cache invalidation from the tests.
9e34880 to
822104c
Compare
Build protobuf as a shared Conan dependency so OpenCV-backed OpNav and vizInterface bindings use one runtime without crashing at interpreter shutdown. Add subprocess import-order coverage for source builds and optional wheels, and document the resolved issue.
- let optional wheels declare build features through entry-point metadata - preserve core build provenance while detecting installed feature providers - reject optional providers that do not match the core Basilisk version - validate the intentional build-metadata delta used to create extension wheels - test feature discovery, metadata failures, and optional-wheel installation states - document feature guards for monolithic and split-wheel installations
Description
This PR prevents interpreter-shutdown crashes on macOS when OpenCV-backed OpNav modules and
vizInterfaceare loaded in the same process. Protobuf is built as a shared Conan dependency on macOS so both consumers use one runtime.It also extends
Basilisk.hasBuildFeature()to aggregate capabilities provided by the core artifact and separately installed optional wheels. Optional wheels advertise their features through package entry-point metadata and must match the core Basilisk version.The commits are organized as follows:
vizInterfacein either order.Verification
bsk-opnavwheel updates the reportedopNavcapability as expected.git diff --checkpass.No test baselines were changed.
Documentation
Updated the following documentation:
Reviewers should verify the documented behavior of
getBuildInfo()versushasBuildFeature(), particularly that the former preserves core build provenance while the latter reports aggregate installed capabilities.Future work
Future optional Basilisk wheels can use the same entry-point metadata mechanism to advertise their build capabilities. No additional wheel splits are included in this PR.