Pypy7.3.15

[mattip]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [ ] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [ ] Ensured the license file is being packaged.

Closes #115 (once the ppc64le build is uploaded manually)

Updates PyPy to 7.3.15, which replaces #114. Also creates a python3.10 package for pypy, which solves conda-forge/pypy-meta-feedstock#32. This is a convenience, and is not meant to trigger a migration. People who want to use python3.10 with PyPy will need to install packages from pip.

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[mattip]

it'd be almost "for free" to catch up

Nothing is ever for free. With only 1385 packages migrated and nearly 400 packages still in transit, the pypy38/39 migration is far from finished. I thought the 3.10 package would JustWork, and it seems there are problems, like https://github.com/pypy/pypy/issues/4883

[mattip]

Reminder: once this gets merged, I should use this workflow to create and upload ppc64le and aarch64 packages

[h-vetinari]

Nothing is ever for free. With only 1385 packages migrated and nearly 400 packages still in transit [...]

My point was not about those in transit, but those already built for pypy3.9. Based on previous migrations and pypy's focus on compatibility, I expect the vast majority of feedstocks already being built for pypy3.9 to build essentially unchanged for pypy3.10 as well. That's what I meant by "catching up with the feedstock coverage".

If indeed there is a lot of breakage by going from 3.9 and 3.10 (like apparently https://github.com/pypy/pypy/issues/4883), then that argument is moot, but I think that should be rare. In any case, the migration discussion is completely separate, and just building 3.10 already would be cool.

[mattip]

I uploaded the aarch64 and ppc64le packages to https://anaconda.org/mattip/pypy3.9/files and marked them as "copy". Here are the logs

aarch64-log.txt ppc64le-log.txt

@isuruf could you check the logs and copy the packages to the proper place?

[h-vetinari]

Here are the logs

I just had a look, and I see that there are several builds in those logs (for aarch)

BUILD START: ['pypy3.8-7.3.11-hca25ad7_0.tar.bz2']
BUILD START: ['pypy3.8-7.3.11-hf9a8208_0.tar.bz2']
BUILD START: ['pypy3.9-7.3.11-h3253541_0.tar.bz2']
BUILD START: ['pypy3.9-7.3.11-h21982c9_0.tar.bz2']
BUILD START: ['pypy3.9-7.3.15-h63376dd_0.tar.bz2']

The last one matches what you uploaded, so I assume that's the correct log, but next time please only copy the logs for the respective build. The build logs itself look fine, though there's a bunch of noise coming from - pypy3 -m test.test_ssl (including stacktraces), but I'm assuming that's part of the test suite, and that pypy would exit with a non-zero exit code if the tests fail?

[mattip]

I see that there are several builds in those logs

Sorry.

I'm assuming that's part of the test suite, and that pypy would exit with a non-zero exit code

Yes. That can be confirmed in the py3.10 runs, which fail that test and is why I excluded 3.10 from this PR.

[h-vetinari]

Copied!

>set "LABEL=copy"
>set "DELEGATE=mattip"
>set "PACKAGE_VERSION=7.3.15"
>anaconda copy --from-label %LABEL% --to-label main --to-owner conda-forge %DELEGATE%/pypy3.9/%PACKAGE_VERSION%
Using Anaconda API: https://api.anaconda.org
Copied file: linux-aarch64/pypy3.9-7.3.15-h63376dd_0.tar.bz2
Copied file: linux-ppc64le/pypy3.9-7.3.15-h4020351_0.tar.bz2
Copied 2 files!