<antocuni>
I would like to be able to use a "+", but I don't know if it causes problems on e.g. windows. E.g.:
<antocuni>
hpy-1+cpython-38d
<antocuni>
uhm, maybe I should as on discord :)
mattip has quit [Ping timeout: 252 seconds]
<fangerer>
concerning Windows: I'm happy to try it out. I've setup a Windows 10 VM particularly for debugging HPy problems 🙂
mattip has joined #hpy
<antocuni>
fangerer: thank you! What is the filename extension of a normal CPython C extension on windows?
<fangerer>
give me a minute to boot the VM
<fangerer>
So, on my Python 3.10.7 running on Windows 10 (64-bit): `sysconfig.get_config_var('EXT_SUFFIX') == '.cp310-win_amd64.pyd'`
<antocuni>
so, completely different than linux
<antocuni>
although it makes more sense because it seems more closely related to the name of the wheels
<antocuni>
ah, I found a trick: if I go to e.g. https://pypi.org/project/psutil/#files I can download wheels for all platforms and look directly at the filenames
<fangerer>
I'll take care of it. I hope that I can finish it today. When exactly do you need it?
<antocuni>
fangerer: and I suppose that the '-native' part is important, right?
<antocuni>
it's annoyingly hard to find a generic way to parse it
<antocuni>
because it seems that the number of "parts" separated by dashes is vastly different between cases, and you care about a different subset of those
<antocuni>
pff
dalley has joined #hpy
<fangerer>
yes, the `-native` part is specific to graalpy because we also have a managed mode
<antocuni>
I gave up writing a generic parser and resorted to do a big if/elif 😅
<fangerer>
😄
<mattip>
fangerer: it would be nice to have early next week, but
<fangerer>
already on it; I think I can finish today
<mattip>
it seems that these things get lost quickly, so today would be nice
<antocuni>
I pushed my changes
<antocuni>
fangerer (or any other graalpy dev): could you please check that this is doing something reasonable for graalpy?
<mattip>
antocuni: am I confused? As I understand things, "hybrid" and "legacy" mode need to link to the python so, so they are not different from any python c-extension
<mattip>
and should use sysconfig['SO'] always
<antocuni>
no
<antocuni>
hybrid is a .hpy.so which also links against Py_* symbols
<antocuni>
but it has a HPy_Init* symbol
<antocuni>
so must be loaded by hpy.universal.load()
<antocuni>
we don't have any "legacy" mode
<antocuni>
we have "cpython" mode which is what you say and indeed uses sysconfig['EXT_SUFFIX']
<fangerer>
> fangerer (or any other graalpy dev): could you please check that this is doing something reasonable for graalpy?
<fangerer>
will do but probably tomorrow; I need to run ...
<mattip>
ok, why not use the same "platform tag" as the sysconfig["EXT_SUFFIX"] ? is the problem it is too hard to find this formula?
<antocuni>
there is no good way to factor out the "platform tag" from EXT_SUFFIX
<antocuni>
if you look at the examples, you see that the format is widely different
<antocuni>
e.g. cpython/linux is very different thatn cpython/windows
<mattip>
yes, but the different platforms are consistent with themselves. So you will need specific linux/macos/windows code to produce the platform tag
<antocuni>
but yes, my first idea was to include the platform tag, i.e. to have .hpy0-x86_64-linux-gnu.so
<antocuni>
but then I realized that CPython itself does something different for abi3, for which it just uses .abi3.so
<antocuni>
so I wanted to do the same for hpy
<antocuni>
mattip: do you think that my current solution is problematic in any way? Note that the filename is not very important, because it's always passed as an argument to hpy.universal.load()
<antocuni>
e.g., until now it was called '.hpy.so' even ON WINDOWS and it worked 😅
<mattip>
it only matters if the names might conflict
<mattip>
if files from different versions are in the same directory
<antocuni>
different versions of what?
<mattip>
which in practice never happens
<mattip>
of anything: python version + platform version + implementation
<antocuni>
yes, I don't think this is a case that we want to handle honestly
<antocuni>
and .abi3.so has the same "problem" so if it's fine for them, it's fine for us
* antocuni
afk
<mattip>
theoretically, abi3.so only needs to deal with platform version conflict, python version and implementation don't matter