Open to adding PyInstaller releases?

[jcbhmr]

Why this might be good:

• Allow users who don't have pip installed (Windows especially) to use Bikeshed by downloading a .zip file with a runnable bikeshed.exe in it
• Easier for downstream distributors (VS Code extension preview, npm bikeshed package, etc.) to re-package Bikeshed without requiring Python
• Would encourage use of GitHub releases instead of Release Notes #1773

Why this might be bad:

• Requires first-time code to do the thing
• Now instead of making it work with pip distribution only you need to make it work with PyInstaller and pip distribution
• Would need to use GitHub release artifacts instead of or in addition to Release Notes #1773

Is this something that you'd be open to accepting contributions for? I have https://github.com/jcbhmr/bikeshed my current fork which does what I need it to do quite well. I would like to (if possible) contribute the PyInstaller stuff back to this project.

[tabatkins]

As long as it doesn't require meaningful additional effort per release, yeah, I'm fine with this. Right now, releasing a new version to pip is just running a script. What would the new method look like?

[jcbhmr]

I assume you mean release.py which you run from your own computer?

The meaningful effort per-release is either:

1. adding a github personal access token to your env, secrets, or wherever that has permission to trigger a github workflow on this repository (to build for all and tag and release on github) and trigger that workflow from release.py after publishing to pypi. this splits the "where it all happens" into two: pip is published from your PC and pyinstaller stuff happens in CI
2. revamp your release workflow to move the "place where it all happens" in CI and publish pyinstaller & pip stuff from github actions. you could even use release.py as a dummy trigger to just invoke gh workflow run locally lol
3. continue as-is with no modifications to release.py and just remember to manually trigger the "do the second part of release: github release + pyinstaller" workflow through the github web UI after running release.py locally

the one that is the least change-y codewise is option 3
the one that I would pick in a greenfield project is option 2
option 1 is sort of a compromise but seems like it could be brittle

the reason you need ci somewhere in there is to do the macos, windows, linux matrix which (given my assumption about "run release.py locally") you cant do on a single computer; you need runs-on: ${{ matrix.os }}

I like option 2. heres more details:

this is pretty much the entire code you'd need

.github/workflows/release.yml

name: Create release
on:
  workflow_dispatch:
    inputs:
      pypi:
        type: boolean
      draft:
        type: boolean
jobs:
  # https://docs.pypi.org/trusted-publishers/
  pypi-publish:
    if: inputs.pypi
    name: Upload release to PyPI
    runs-on: ubuntu-latest
    environment:
      name: pypi
      url: https://pypi.org/p/bikeshed
    permissions:
      id-token: write  # IMPORTANT: this permission is mandatory for trusted publishing
    steps:
      # retrieve your distributions here
      - run: idk

      - name: Publish package distributions to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1
  build:
    strategy:
      fail-fast: false
      matrix:
        include:
          # https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#platform-tag
          # python -c 'import sysconfig; print(sysconfig.get_platform().replace("-", "_").replace(".", "_"))'
          - { os: ubuntu-latest, target: linux_x86_64 }
          - { os: macos-latest, target: macosx_11_0_arm64 }
          - { os: macos-13, target: macosx_10_9_x86_64 }
          - { os: windows-latest, target: win_amd64 }
    defaults:
      run:
        shell: bash
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - run: pip install -e .
      - run: pip install pyinstaller
      - run: bikeshed update
      - run: pyinstaller -y --name=bikeshed --collect-all=bikeshed ./bikeshed.py
      - env:
          target: ${{ matrix.target }}
        run: |
          version=$(cat bikeshed/semver.txt)
          mkdir stage
          mv dist/bikeshed stage/bikeshed-$target-$version
      - uses: actions/upload-artifact@v4
        with:
          name: bikeshed-${{ matrix.target }}
          path: stage
  version:
    outputs:
      version: ${{ steps.version.outputs.version }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - id: version
        run: |
          version=$(cat bikeshed/semver.txt)
          echo "version=$version" >> "$GITHUB_OUTPUT"
  gh-release-create:
    needs: [build, version]
    permissions:
      contents: write
    runs-on: ubuntu-latest
    env:
      version: ${{ needs.version.outputs.version }}
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: bikeshed-linux_x86_64
      - uses: actions/download-artifact@v4
        with:
          name: bikeshed-macosx_10_9_x86_64
      - uses: actions/download-artifact@v4
        with:
          name: bikeshed-macosx_11_0_arm64
      - uses: actions/download-artifact@v4
        with:
          name: bikeshed-win_amd64
      # https://github.com/actions/upload-artifact/issues/38
      - run: chmod +x bikeshed-linux_x86_64-$version/bikeshed
      - run: chmod +x bikeshed-macosx_10_9_x86_64-$version/bikeshed
      - run: chmod +x bikeshed-macosx_11_0_arm64-$version/bikeshed
      - run: tar czf bikeshed-linux_x86_64-$version.tar.gz bikeshed-linux_x86_64-$version
      - run: tar czf bikeshed-macosx_10_9_x86_64-$version.tar.gz bikeshed-macosx_10_9_x86_64-$version
      - run: tar czf bikeshed-macosx_11_0_arm64-$version.tar.gz bikeshed-macosx_11_0_arm64-$version
      - run: zip -r bikeshed-win_amd64-$version.zip bikeshed-win_amd64-$version
      - env:
          GH_TOKEN: ${{ github.token }}
          GH_REPO: ${{ github.repository }}
        run: |
          gh release create "v$version" \
            ${{ (inputs.draft && '--draft') || '' }} \
            --generate-notes \
            bikeshed-linux_x86_64-$version.tar.gz \
            bikeshed-macosx_10_9_x86_64-$version.tar.gz \
            bikeshed-macosx_11_0_arm64-$version.tar.gz \
            bikeshed-win_amd64-$version.zip

and heres what you'd actually do to trigger a release

you can make it a draft and edit the release to provide more detailed release notes or add a releasenotes markdownbox to the "run workflow" dialog to add more notes

this is how I'm currently doing things with my bikeshed fork. its particularly nice since I don't have to open an ide or terminal to create releases -- its all done in the web interface by triggering a CI job. that can also be a downside if you prefer the terminal and local stuff.

btw to clarify I'm happy doing any of the three options or whatever fits your workflow

[tabatkins]

Excellent, that's very thoro. I'll review and do something about it.