Re: Installation layout of the PyPy 3.8 Fedora package
Miro Hrončok <[email protected]> Mon, 6 Dec 2021 12:30:18 +0100
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <[email protected]> |
On 04. 12. 21 19:18, Matti Picus wrote: > On 2/12/21 8:45 pm, Miro Hrončok wrote: > >> Hello PyPy folks, >> >> I co-maintain the PyPy and CPython interpreter packages in Fedora > > > Thanks for supporting PyPy > > >> We basically took the advice from https://doc.pypy.org/en/latest/build.html >> > > That documentation may now need some updating. > >> Several different versions of pypy (e.g. 3.6 and 3.7) could be installed >> alongside each other, as long as only one of them "owned" /usr/bin/pypy3. >> >> >> This e.g. means that the standard library is installed in: >> >> /usr/lib64/pypy3.8/lib/pypy3.8/ >> >> Or the header files are in: >> >> /usr/lib64/pypy3.8/include/pypy3.8/ >> >> Double namespacing like this seems a bit overengineered, and since the idea >> was to resemble CPython, I was aiming at this setup: >> ... > > > It seems reasonable that PyPy should follow CPython's lead in layout. > >> Which would be the exact copy of our CPython setup | sed s/python/pypy/ >> > Indeed, that is the goal. OK, let's focus on this goal for PyPy 3.9. >> However, I found 4 problems: >> >> 1) The PyPy install scheme only has "lib", not "lib64" >> >> I think we could sort this by a tiny patch that we used to carry in CPython >> 3.8 before configurable platlibdir was introduced in 3.9. >> > If it is part of CPython 3.9, it should be part of PyPy 3.9 as well. Can you > check that the latest nightly at https://buildbot.pypy.org/nightly/py3.9/ > indeed no longer needs that change? The standard library is prepared for this, but when building CPython 3.9+, we pass --with-platlibdir=lib64 to configure. I wouldn't know where to pas this to PyPy build. >> 2) The /usr/include/PyPy.h file is *not* namespaced with PyPy Python version >> >> I don't know if we even need to ship this file. It seems deprecated. Maybe it >> can be in /usr/include/pypy3.8/PyPy.h? >> > I was confused by this as well. As Armin pointed out, it was part of the older > cffi embedding code, and I think it can be dropped. See > https://foss.heptapod.net/pypy/pypy/-/issues/3608 Ack. >> 3) /usr/bin/pypy3.8 is a symbolic link to /usr/bin/pypy3 >> >> I would expect it to be the other way around > > > This makes sense. For testing, we need pypy3, but can create it as a symlink > already as part of the build. I can easily change the symlink order downstream. But if done upstream, it would make more sense. >> 4) The /usr/bin/libpypy3-c.so file is *not* namespaced and seems misplaced >> >> This is the one thing I cannot wrap my head around. I do not wish to install >> this file "globally" to /usr/bin > > > This also makes sense and some ideas were floated in other responses to this > thread. It would be best if someone with a plan could open an issue for > discussion, and even better a PR. Well, I have a plan that would work for Fedora (have /usr/lib64/libpypy3.9.so(.1.0)), but I am not sure how to implement it. >> So, I am asking on this list: How should we package PyPy 3.8 for Fedora? Do >> we need to install it to /usr/lib64/pypy3.8/ prefix even thou most (but not >> all) of the directories within would contain a "pypy3.8" subdirectory? Or is >> there a better option I do not yet see? >> > While it is too late for pypy3.8, now is the time to tweak pypy3.9. I am not > sure what support you expect from PyPy to recreate the same layout as the one > used in CPython. OK, so for me, there are now 2 problems :) 1) How to package PyPy 3.8. 2) Help make PyPy 3.9 more like CPython 3.9 in this regard. I suppose for (1) we can live with "weird" paths for a while. > Are there patches we can upstream? Not yet. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ pypy-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-dev