pypy3.8 (new formula) pypy3.9 (new formula) #117699
Conversation
BrewTestBot
added
the
automerge-skip
|
@tonybaloney Thanks. I think pypy 3.8 and 3.9 are wished on Homebrew. pypy 7.3.10 that supports Apple M1 was released a few days ago. Bump please. Here is some conversation on Homebrew. https://www.pypy.org/posts/2022/12/pypy-v7310-release.html#utterances-thread |
|
@HIRANO-Satoshi have updated for 3.7.10 on PyPy3.8 and PyPy3.9. I don't have an ARM64 machine to test on but I'll ask around for someone to try the formula |
|
You seem an expert of Python. If you can't find a person for test, I will test, if you are OK that I'll throw error msgs to you if there are, as I don't think I can fix them. |
|
Working well locally. Ready for review |
|
For anyone who can test on macOS M1/M2 : $ <clone this branch>
$ brew install --build-from-source Formula/pypy3.8.rb
$ pypy3.8Building from source can take up to an hour |
|
Failed build in 3.8 forumulae |
|
On the CI , it is failing to find a header from the xcode-provided tkinter. I don't know how to solve this. What does CPython do? I suggested a work-around in the 3.7 recipe that should be applied to 3.8 and 3.9 as well. |
|
Note that PyPy has dropped support for PyPy3.7, latest security patches were not applied to it. |
The main python package doesn't build with tk support, and even python-tk doesn't depend on X11 so seems to somehow turn it off |
Cool, so the suggestion to use |
The redirect for "pypy" currently goes to 3.7, so it can be updated to 3.8 if there's consensus |
pypy.rb and pypy3.7.rb have this. I had the same error when I removed the above line from pypy.rb. |
Only 3.8 and 3.9 support ARM64 so that line is there for a Reason. Try the 3.8 recipe instead |
|
I tried 3.8 as you wrote and failed. pypy3.8.rb has I don't know why I failed when I removed |
|
I wrote the following a few ours ago, but maybe I misunderstood. If we need a bootstrap Pypy to compile a target Pypy, the first one should be compiled with brew in x86_64 environment. While x86_68 brew is installed in /usr/local, arm64 brew is installed in /opt/homebrew. |
|
I'm afraid that I'm misunderstanding, if we need pypy3.7 with x86_64 brew installation to build arm64 Pypy, that requires too much disk space and time and users don't want to do so. Is it possible just download prebuilt binaries from pypy.org into /opt/homebrew/Cellar and make symlinks to /opt/homebrew/bin? |
|
Homebrew software must be compiled from source. We can download binaries to bootstrap the source though. |
|
I understand. |
|
Current build error is : I've seen some related issues in the PyPy backlog but nothing conclusive, @mattip do you know how to fix this? I noticed the current formulae targets openssl@1.1 as a dependency, but the source code seems to refer to v3. so I could try and set openssl@3 as the dependency. |
|
Second build error is This one is strange because it's set |
Formula/pypy3.7.rb
Outdated
| @@ -115,7 +93,7 @@ def install | |||
| def post_install | |||
| # Precompile cffi extensions in lib_pypy | |||
| # list from create_cffi_import_libraries in pypy/tool/release/package.py | |||
| %w[_sqlite3 _curses syslog gdbm _tkinter].each do |module_name| | |||
| %w[_sqlite3 _curses syslog gdbm].each do |module_name| | |||
| quiet_system bin/"pypy3", "-c", "import #{module_name}" | |||
| end | |||
There was a problem hiding this comment.
This whole post_install stanza seems redundant to me. The package.py script already does the cffi build. What happens if you remove it (from all the scripts?)
|
The recipe is failing with From what I can tell that error comes from ruby. The PyPy build process does not use ruby, is something else going on that is not reported in the log? |
|
There was a bug in the release. See issue 3865 where macos-x86_64 will not run. The patch is this commit. It is not clear to me if this is "older macos x86_64 will not run" or "any macos x86_64 will not run on x86_64 hardware". I test the macos builds on a M1, I do not have x86_64 hardware. |
For a solution from a different context, I've found that this doesn't occur on GitHub Actions thanks to brew's libx11 being installed by default there. |
chenrui333
force-pushed
the
pypy3-updates-revisited
branch
from
bb5e4d3
to
adfc8f1
Compare
chenrui333
added
CI-long-timeout
|
This is still failing with |
|
I still think the path forward here is to package PyPy without tcl/tk, like CPython. The way to do that is in the linked comment. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
It is a shame that this is so close and yet cannot be pushed over the finish line. Can't the PR be modified to use |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
Over at #126697, @carlocab suggested that the tk/tcl errors simply be ignored (if I understand correctly). So I think the path forward is to restructure the commits here, in accordance with this comment:
@tonybaloney could you do that? |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
The PyPy3 formula is PyPy3.7.
There are major versions 3.8 and 3.9. These are not compatible with 3.7, so they should be optional versions (just like Python 3.7, 3.8 etc)
This PR adds 3.8 and 3.9.
3.8 and 3.9 also support ARM64, so in these formulae, the x86_64 constraint has been removed.
This is from #96305 which got closed by a bot
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?TODO: