chore(packaging): pin venvstacks as dev dep + auto-detect driver#1355
Merged
Conversation
Make the venvstacks version that produces the macOS app bundle
reproducible across contributors by declaring it as a dev dependency
in pyproject.toml. Today `pipx run venvstacks` silently picks up
whatever PyPI release happens to be current on the day a given
contributor builds — two of us can build the same commit and get
subtly different output if venvstacks shipped a release in between.
Changes:
- pyproject.toml: add `venvstacks>=0.7.0` to both
`[project.optional-dependencies].dev` (pip path) and
`[dependency-groups].dev` (PEP 735 / uv path), matching the
existing pair-maintained pattern for pytest/black/etc.
- packaging/build.py: replace the three hardcoded `pipx run venvstacks`
invocations with a `_venvstacks_driver()` helper that picks
whichever is available, in priority order:
1. `venvstacks` directly on PATH (installed via the dev extra)
2. `uvx venvstacks` (uv's pipx-equivalent)
3. `pipx run venvstacks` (historical default)
Bails with an actionable remediation hint when none are present.
- README.md: update the macOS build prerequisites paragraph to point
at the dev extra as the canonical install path. Translated READMEs
not touched — kept for Jun's regular translation-sync pass.
End-user `.app` bundle is byte-identical; this is purely a build-time
reproducibility + host-dependency-footprint change. Contributors using
pip-only workflows are unaffected (pip resolves the dev extra and the
direct-on-PATH branch takes over); pipx-only setups remain functional
via the third fallback.
a6b44b8 to
a819b2f
Compare
Owner
|
Thanks. Pinning the producer alongside everything else it ships removes a real source of "works on my machine" drift, and the three-tier driver fallback keeps the existing pipx workflow working without any contributor churn. Merging now. |
This was referenced May 27, 2026
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 27, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
1 task
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 28, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 28, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 28, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 29, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 29, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
May 30, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 1, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 2, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 2, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 3, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 3, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 5, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 5, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
cfbraun
added a commit
to cfbraun/omlx
that referenced
this pull request
Jun 6, 2026
After jundot#1355 retired packaging/build.py's .app + DMG pipeline, nothing in the repo creates a .dmg — apps/omlx-mac/Scripts/build.sh produces oMLX.app directly. The packaging README still told developers to "Open the DMG produced by the Swift build", which doesn't exist. For local builds the .app is sufficient: drag it to /Applications or open it in-place. No wrapper needed. The Releases DMGs come from a maintainer-side pipeline not present in this tree; that's a separate distribution concern and explicitly called out. Closes jundot#1456.
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
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.
Summary
This PR is raised for the reason someone wants to build App locally.
packaging/build.pycurrently invokes venvstacks viapipx run venvstacks …in three places. That works, but the version of venvstacks that produces the macOS app bundle is whatever PyPI release happens to be current on a given contributor's machine the day they build — there's no lockfile discipline on the tool that produces the artifact. Two of us can build "the same" commit and get subtly different output if venvstacks shipped a release in between.This PR pins venvstacks the same way we pin every other dep that affects the bundle:
pyproject.toml:venvstacks>=0.7.0added to both[project.optional-dependencies].dev(pip-managed venvs) and[dependency-groups].dev(PEP 735 /uv sync --dev), matching the existing pair-maintained pattern for pytest/black/ruff.packaging/build.py: a new_venvstacks_driver()helper auto-detects an available driver in priority order:venvstacksdirectly on PATH (installed via the dev extra — fastest path, no tool-runner startup overhead)uvx venvstacks(uv'spipx runequivalent)pipx run venvstacks(historical default — backwards compatible)Exits with an actionable remediation hint when none are present.
README.md: updated the macOS build prerequisites paragraph to point at the dev extra as the canonical install path. Translated READMEs intentionally not touched — kept for the next translation-sync pass.Why this matters
The
.appbundle ships to end users is the contract; venvstacks is what produces it. Making the producer reproducible is a small but load-bearing step toward the broader distribution story.Compatibility
pip install -e ".[dev]"brings venvstacks into the active venv, and the driver-detection helper finds it via the direct-on-PATH branch.uv sync --devinstalls venvstacks; same direct-on-PATH branch picks it up.uvx venvstacksis also available as a fallback for cases where someone runsbuild.pyoutside an active venv..app: byte-identical. This is purely a build-time-reproducibility + host-dependency-footprint change.