Why don't you try some CI?

[DiddiLeija]

GitHub has the ability of having CI (Continous Integration) to run things on each commit. It can be also useful for checking PRs, running linters, etc. A good start would be GitHub Actions, but you can try other things.

If you like the idea, and would need help, please ping me.

[kitao]

@DiddiLeija. Yes, if possible, I'd like to use CI though I've never used GitHub Action or Travis CI.
Can those services check the operation of the screen? In the case of Pyxel, I need to check not only compilation but also screen output.
Anyway any setting example is welcome. Thank you.

[DiddiLeija]

Probably, we can start with linters, to check the code quality. Maybe later we can start with more stuff.

[merwok]

xvfb-run can be used to run graphical programs, but I’m not sure if the screen can be captured and such things.

CI would still be useful to check that the PRs have code that builds, passes linter checks, has documentation, etc.

[DiddiLeija]

What about setting up Nox or something similar? We can use this automation tools on GitHub via GitHub Actions, and the developers can run exactly the same on their local forks.

[merwok]

Big user of tox personally, but these are just tools that install dependencies and run commands, the question is still: what commands would be worth running? :)

[DiddiLeija]

I was thinking about:

• flake8 (which we already have configured)
• isort (to see if the imports are correectly sorted)
• black (should we adopt this?)

We can also run pip install . on the env (either a Nox or tox env), as an additional step before the others.

[DiddiLeija]

Also, we can try pre-commit, and decide between a just-check CI or enable pre-commit to fix found issues.

[kitao]

Regarding lint, Pyxel already has its standard commands and settings which are combination of rust format, clipper, black and isort. those can be executed with make format automatically.
I also would like to build and get artifacts for each platform automatically.
Now Pyxel supports x64 Windows, Intel Mac, M1 Mac, Intel Linux. And ARM Linux is also supported but self compilation is necessary. Binaries for Mac are cross compiled and merged into one library as fat binary.
Instructions for those are written in the pyxel/Makefile file.

I have started the research for GitHub Actions. However, there are other things to do for Pyxel, and it seems that it will not end soon.

[merwok]

I have some experience with Github Actions, I will add some simple config on my fork and send a PR at some point.
Also interested in building wheels automatically — I know about the cibuildwheel tool but haven’t had a need to use it so far!

[kitao]

Thank you!
For your reference, one of the unique point in Pyxel build toolchain is that it uses Pyoxidizer and Inno Setup.
After building libraries for every platform, Pyxel build python wheel, then make standalone binaries with the wheel by using Pyoxidizer. Pyoxidizer integrates the Python interpreter and Pyxel libraries into one executable file.
And only for Windows, Pyxel call Inno Setup to make installer file finally.

[erickisos]

I have some experience with Github Actions too, but I would agree with the message of @DiddiLeija , it would be great to start with something simpler like Code Quality checks, and I don't know if something like dependabot make sense for you folks.

I mean, if I can help with something it would be great, just to avoid adding the same things as @merwok

[kitao]

Current Pyxel has already an auto build action. Recent releases were built by it.
https://github.com/kitao/pyxel/blob/main/.github/workflows/release.yml

[DiddiLeija]

Something we can do is adding something like a ci.yml file (or any other name, I personally like this one), and add a few steps:

1. Install the Rust / Python dependencies
2. Install tox, or Nox (that's your decision) via pip
3. Use the automation testing tool (from step 2) to run, with just one command, all our linting.

The main advantage of using the tools from step 2 is that both users (in a local clone) and CI (here, at GitHub) will run the same tests and linters, so we can follow the same code style.

Also, if we set up GitHub Actions, we can run the same CI under (almost) every OS we support, and every Python we support.

---

Here's a quick example I borrowed from one of my projects, see https://github.com/DiddiLeija/diddi-and-the-bugs/blob/main/.github/workflows/ci.yml. I modified it a bit to show some features we can use:

name: Python CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: $ {{ matrix.os }}  # We can run this on several OS, see below
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        python-version: [3.7, 3.8, 3.9, "3.10"]  # "3.10" goes quoted here!

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v2
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install pip dependencies
      run: |
        # Obligatory stuff. We can install tox instead of nox, too
        python -m pip install --upgrade pip setuptools nox
        # Our own deps
        python -m pip install -r requirements.txt
    - name: Run linters with Nox
      run: |
        # If we are using tox, it would be something like "tox -e {python-version} ..."
        nox --non-interactive -s check-quality

Of course, our Pyxel CI will be more complex, but it's an example.

[kitao]

Now Pyxel has its own actions for release task.
In the future, I would like to welcome any suggestions based on that, but since the prerequisites for this thread have changed from before, I would like to close it once. Thank you for your understanding.