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