Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

sarnold
Copy link

@sarnold sarnold commented Mar 1, 2025

  • update workflow action/python versions and packaging, remove errors from setup.py
  • add workaround for py39 on macos installed with broken setuptools
  • update python matrix and expand tox file with build/check/clean cmds

Sorry, I couldn't wait for open PRs to merge so I tested the 2 C-compat PRs (#306 and #308) and this cleanup PR in the relevant workflow and our project CI is Green again. This PR also contains a GH release workflow to publish GH release from a tag push. Thanks!

* add workaround for py39 on macos installed with broken setuptools

Signed-off-by: Stephen L Arnold <[email protected]>
@aaronliu0130
Copy link
Member

I don't understand the pupose of the tox.ini changes. And I don't like the idea of a release workflow as we also need to concurrently release on PyPI.

I actually plan to finish another refactoring of the workflow as you can see at #307 . Could you test that on non-Windows stuff and disregard the "deprecated module" error?

fail-fast: false
matrix:
os: [ubuntu-22.04, macos-latest, windows-latest]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
os: [ubuntu-22.04, macos-latest, windows-latest]
# macOS in Intel, macOS on ARM, Ubuntu on x64, Ubuntu on ARM, Windows on X64
os: [macos-13, macos-latest, ubuntu-latest, ubuntu-24.04-arm, windows-latest, windows-2025]

cache: 'pip'
cache-dependency-path: '**/test-requirements'
env:
SETUPTOOLS_USE_DISTUTILS: ${{ matrix.os == 'macos-latest' && matrix.python-version == '3.9' && 'stdlib' || 'local' }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distutils is history. Let’s drop it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still required until py39 and py310 are history

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not true.

- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install -e .[dev]
python -m pip install 'tox-gh-actions<4.0.0'
pip install tox tox-gh-actions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really needed with tox -e py in GitHub Actions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tox -e py is implicitly selecting whatever python version is the environment default and we don't want that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We specified the Python environment in the python action step.

cache: 'pip'
cache-dependency-path: '**/test-requirements'
env:
SETUPTOOLS_USE_DISTUTILS: ${{ matrix.os == 'macos-latest' && matrix.python-version == '3.9' && 'stdlib' || 'local' }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distutils is history.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is about specifically what versions of bundled python modules are installed with the (now older) python on the Github CI runners. It has nothing to do with the project packaging.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and we don't need distutils in any Python version.

@aaronliu0130
Copy link
Member

aaronliu0130 commented Mar 2, 2025 via email

@sarnold sarnold force-pushed the workflows-packaging-tox branch 2 times, most recently from 574de9c to 2d52dec Compare March 3, 2025 02:20
…lease

* py313 is not quite ready yet but everything else should be green

Signed-off-by: Stephen L Arnold <[email protected]>
@sarnold sarnold force-pushed the workflows-packaging-tox branch from 2d52dec to 5503276 Compare March 3, 2025 02:23
@sarnold
Copy link
Author

sarnold commented Mar 3, 2025

I don't understand the pupose of the tox.ini changes. And I don't like the idea of a release workflow as we also need to concurrently release on PyPI.

It's just release automation, and should work for pypi if you uncomment the last job.

I actually plan to finish another refactoring of the workflow as you can see at #307 . Could you test that on non-Windows stuff and disregard the "deprecated module" error?

That ^^ refactor branch is broken in CI for the py313 issue, as well as on the windows CI runners. Works on linux and macos with the same distutils workaround.

@aaronliu0130
Copy link
Member

  1. I fixed the Windows problem today.
  2. This doesn't fix the py313 thing either.

Copy link
Member

@aaronliu0130 aaronliu0130 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time to write all this! We definitely could use release automation, but as it stands I feel like this is too overcomplicated. You'll also probably need to rework this after the tox.ini changes in #317 are merged.

bash

deps =
-e .[test,dev]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an advantage for this over "extras"?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Visibility? otherwise it's just -e .

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that change anything? AFAIK tox sandboxes the environment anyways.

Comment on lines +28 to +44
passenv =
DISPLAY
XAUTHORITY
HOME
USERNAME
USER
XDG_*
CI
OS
PYTHONIOENCODING
PIP_DOWNLOAD_CACHE

setenv =
PYTHONPATH = {toxinidir}

allowlist_externals =
bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these really needed?

strategy:
fail-fast: false
matrix:
os: [macos-15, macos-latest, ubuntu-latest, ubuntu-22.04, ubuntu-24.04-arm, windows-latest, windows-2025]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought wheels were platform-independent.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-platform wheels are, but the point here is the platform environments are different.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I don't quite get what you're saying. Could you elaborate on the possible differences?

Copy link
Author

@sarnold sarnold Mar 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite get what your objection and/or alternative is. Can you elaborate more on what you want? I'm not trying to be weird here, but the really simple/short workflows don't seem to "last" very long due to arbitrary changes in runner environments. I just had to fix coverage workflows in several different repos this week after GitHub suddenly decided to stop finding the right version ov llvm-cov (after the same workflows were working fine for literally years).

@@ -1,20 +1,100 @@
[tox]
envlist = py38, py39, py3.10, py311, py312, pypy3
envlist = pypy3,py3{9,10,11,12,13}-{linux,macos,windows}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fairly sure a machine where you run tox can only have one OS loaded at a time. Is this needed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That ^^ matrix is how tox constructs env commands, including PLATFORM matrix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the PLATFORM matrix for?

{envpython} -m pytest {posargs:}
{envpython} -m pylint cpplint.py
{envpython} -m flake8 cpplint.py
bash -c 'rm -rf build/ dist/ __pycache__/ *.egg-info/ .coverage'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to specifically use bash here? Why not

Suggested change
bash -c 'rm -rf build/ dist/ __pycache__/ *.egg-info/ .coverage'
rm -rf build/ dist/ __pycache__/ *.egg-info/ .coverage

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case either bash or rm needs to be in the allow list. Bash is usually my default "allow" and that gets used to run any other shell commands. In this it's just "rm".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GitHub workflows have an allowlist for commands?

@@ -11,29 +11,43 @@ concurrency:
jobs:
build-test:
runs-on: ${{ matrix.os }}
defaults:
run:
shell: bash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any bash-specific features used.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better that than dash. It's generally better to set what you want and not let GH runner environment decide.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we're only using sh features.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is a very good addition to any GHA workflow. Keeping to strictly sh is not normal behaviour for devs now - and there are some subtle gotchas when not using an explicit shell , c.f. rhysd/actionlint#374

@cclauss
Copy link
Member

cclauss commented Mar 7, 2025

Please rebase because setup.py has been removed.

@aaronliu0130
Copy link
Member

There's too many problems and conflicts now that Christian's pyproject.toml has been merged. Please separate out the release workflow into a new PR if you wish to pursue it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants