Closed cschwan closed 10 months ago
The changes look alright, in principle, but they should be tested. Have you managed to do it by chance?
Otherwise, we could try to make a dry-run mode of the workflow, where no upload is happening, and manually trigger it (there is the workflow-dispatch
event for this, in case you were not aware).
That's what I did in commit 9d297412ad40c47188523deb47efe68ae1fe2cfc, and then the actions have to be triggered manually, as you said.
That's what I did in commit 9d29741, and then the actions have to be triggered manually, as you said.
Ok, great. I was not aware, you're just ahead of me ;)
Unfortunately, the repository contains /
characters. I'd suggest you replacing /
with @
in your sed
command.
Unfortunately, the repository contains
/
characters. I'd suggest you replacing/
with@
in yoursed
command.
Good catch :+1:!
Actually, I wrote something wrong: we should test that 3.11 is still working (though I'm quite confident it will, it was not officially supported even before the downgrade, so it's not deadly urgent), but this could be done extending the CI range (or switching, according whether you want to test in the CI for EOL Python versions or not).
It seems to work since commit 2d632d3b440c58e4909c8a1518ba07e7e986ffc9, however the output is different, probably due to a different maturin
version being used. @AleCandido please have a look at the wheels in https://github.com/NNPDF/pineappl/actions/runs/5880630299. Instead of a wheel for Python 3.6 we have a tar.gz file there. Do you know what it is?
@cschwan the .tar.gz
is a source distribution (the sdist
), it's not compiled. There is actually no wheel for py3.6.
The CPython 3.6 wheel has never been compiled, not only not uploaded. You can check by yourself searching for Built wheel for
in the logs search box.
Actually, thinking further about the compilation process, it is happening inside a Manylinux container in any case, so the host system is irrelevant: the Python versions discovered are those available in the container in any case.
It seems like the version of Maturin used for EOL (that is the same one we used for long time) is using a container with CPython 3.7-10 and PyPy 3.7. In order to support CPython 3.6 we need to use a Manylinux container that has it installed, or install ourselves inside the container (but it is managed by the maturin-action
...).
However, you could customize maturine-action
passing a Manylinux tag:
https://github.com/PyO3/maturin-action#inputs
Now the game is finding one with CPython 3.6 installed...
This doesn't seem to be a problem, everything seems to work now: https://github.com/NNPDF/pineappl/actions/runs/5887659565.
This doesn't seem to be a problem, everything seems to work now: NNPDF/pineappl/actions/runs/5887659565.
You're right, even though I'm not sure how it is compiling for py3.6 if not present... But I'm not an expert of writing manually Python C extensions (i.e. manually compiling with Python headers and the Python loading mechanism), so I'm missing something for sure.
Because of popular requests we may consider adding support for Python 3.6.