Python 3.13 & numpy 2.0 support

[scarlehoff]

The only changes necessary for numpy 2 were to change from np.<type>_ to np.<type><size>

everything else (meaning, the tests) seem to work ootb. I can evolve fits and benchmarks seem to do ok.

[scarlehoff]

Well, not very useful since banana doesn't work in 3.13 so the actual errors are hidden...
let's see now...

[scarlehoff]

wait what

Why would poetry lock work in my computer but fail to install here?

[alecandido]

Why would poetry lock work in my computer but fail to install here?

The old good question :P

[felixhekhorn]

We should also address #438 here

[felixhekhorn]

Similar story as in NNPDF/banana#78: it wants scipy==1.13.1 (compatible with banana), but only >1.14.1 supports 3.13

[scarlehoff]

I don't know how come locally the code found a path to get an int into the ev_op_max_order argument #441 (comment) I wonder whether there was some cached numba function? I'm quite curious but it doesn't really matter.

What worries / annoys me a bit is that the solution to both this problem and banana's was to run poetry lock without python 3.9 in the toml (so it gets a newer scipy), then running it again with it (then it keeps the newer scipy for 3.13).
Otherwise it tries to use the old scipy for 3.13, which it doesn't find so it tries to build it -> openblas failure.

[felixhekhorn]

What worries / annoys me a bit is that the solution to both this problem and banana's was to run poetry lock without python 3.9 in the toml (so it gets a newer scipy), then running it again with it (then it keeps the newer scipy for 3.13).
Otherwise it tries to use the old scipy for 3.13, which it doesn't find so it tries to build it -> openblas failure.

but this sounds like a poetry bug, no?

[scarlehoff]

I guess? But I don't know whether it is intentional (e.g., versions already in the lockfile take precedence). I don't know enough about poetry to say it is a bug.

[felixhekhorn]

should we postpone the fix for tar to later?

[scarlehoff]

should we postpone the fix for tar to later?

I think the tar fix is more a curiosity than anything elsee at this point.

Question, is the master branch ready for a 0.15.2 release or should I back port this to the commit from 0.15.1 so that other things merged to master are not included?

(the importance is a bit academic, tensorflow/pytorch only work for python 3.13 in their developement versions so I still need to install those two by hand, might as well do so with eko, but I don't mind backporting this, it should be painless)

[felixhekhorn]

Please add a Changelog entry

[felixhekhorn]

Question, is the master branch ready for a 0.15.2 release or should I back port this to the commit from 0.15.1 so that other things merged to master are not included?

I think we are ready. The release procedure is now similar to PineAPPL, but still manual and not automated: 0) merge 1) Adjust the Changelog (make a new version there) 2) make that commit the new version

[scarlehoff]

I think it is better if you do the changelog.

RE the version file, I've reverted it back. imho there's no perfect solution, but what we do in NNPDF/nnpdf is to create a fake _version.py at build time, which gets ignored and imported by the real version.py https://github.com/NNPDF/nnpdf/blob/bf9a8ec9ab0cc3a4bb356732efc1c9077983b06d/pyproject.toml#L121

thinking about this perhaps it would be better if pre-commit would ensure that it gets back to 0.0.0? I wonder whether there's a ready made hook for that...

[scarlehoff]

Could this be merged before master drifts away?

[felixhekhorn]

I think it is better if you do the changelog.

it wasn't that complicated 5fbe230 😇

Could this be merged before master drifts away?

I'll do as soon as the unit tests have passed