Builds failing.

Same thing on master, too, from what I can tell.

This request has been automatically failed because it uses a deprecated version of actions/upload-artifact: v2. Learn more: https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/

You have to keep actions up to date. Old actions stop working. Dependabot can do this, but you need to tell it to group actions, so that upload/download stay in sync.

Please rebase.

Done

@henryiii Would you be willing to help determine why

• Bump the github-actions group with 4 updates #337 is the pypa/cibuildwheel bit is failing in CI while
• Fix failing GitHub Actions by not upgrading pypa/cibuildwheel #338 is passing?

Sure, I believe it's because you have the (default) pining active. Our docs aren't actually correct here, but that does actually affect linux too when installing the testing environment. We pin a core set of dependencies, which is virtualenv and its dependencies, which pins python-discovery, and that causes tox to break, since it needs a really new python-discovery. (BTW, @gaborbernat, tight lower bounds + fast releases is hard to manage!)

For your package, I'd recommend just setting dependency-versions = "latest". There's really very little benefit to pinning these days; it used to be we could pin the build backend (because there was only one, setuptools), which might have improved reproducibility, but now it's pretty much just virtualenv, pip, and build.

This (combined with my kimi-K2.5 analysis of the situation) exposes an issue in cibuildwheel: I know the docs say this doesn't affect linux, the llm noticed we don't even allow linux.depedency-versions to be set (overrides still work, though), but we do take it into account when installing the testing phase (which you saw). We removed this affecting the build in v3.3.0 (also noted by the analysis), but it's still present in the test step for linux.

I'll open an issue in cibuildwheel to see if we can iron this out. At the least, hopefully we can update our pins, but I don't want build 1.4.3 to get pinned (1.4.4 should be out soon), so it will be a few days (has to trickle down to manylinux too).

From @joerick:

I did have a quick look at the tox failure above, and it looks to me that the issue is that package has the setting-

before_build: python -m pip install -U pip && python -m pip install tox

So they install tox in the build venv. but it's only used in the test venv - that could be replaced with test-requires = "tox". I don't think we'd be getting the issues then.

pip install -U can be quite opaque to readers because pip install currently has six --u* options, including --user.

pip install --upgrade makes the intention clearer in code that others will read.

% python3 -m pip install --help | grep "\-\-u"

  --user                      Install to the Python user install directory for
  -U, --upgrade               Upgrade all specified packages to the newest
  --upgrade-strategy <upgrade_strategy>
  --use-pep517                Use PEP 517 for building source distributions
  --use-feature <feature>     Enable new functionality, that may be backward
  --use-deprecated <feature>  Enable deprecated functionality, that will be