Lifting the version requirement of Numpy?

[behackl]

Hello! Over at manim we are currently looking into adding support for Python 3.13, but are running into issues with the windows-latest runner.

As far as we could gather so far, the issue is caused by the runner having to build numpy from scratch as they do not have wheels for the latest version (1.26.4) satisfied by the version pin of moderngl-window, numpy < 2. In the runner we can circumvent this issue by force-installing a more recent version of numpy, but in the long run this is not a great solution.

Would it be possible to consider lifting (or at least relaxing) the version requirement for numpy with the next release of moderngl-window?

Thanks for your efforts!

[behackl]

I actually just looked into this for a little while. It looks like bumping the version requirement of numpy essentially forces to bump the version of trimesh -- but after doing that, the tests pass (modulo one test that I am currently having issues with due to scipy wanting to be compiled from source; but I am pretty sure this is just a local problem on my machine).

(To run the tests, I did have to rewrite the imports of utils and headless to relative ones, do you usually run the tests here from within the tests directory?)

[Tremeschin]

I'm also interested in this, even though I have to wait for numpy-quaternion

I can confirm that cloning the repo, bumping versions to numpy>=2.1.3, trimesh>=4.5.2 (maybe it's better to set them all with ~=?) and running pytest on the root folder, all tests pass successfully, but with no changes!

@behackl Maybe you accidentally have a 32 bit python for it to try compile scipy from source? seems to be the only major ones misssing on pypi, you can check by running python3 -c "import struct; print(struct.calcsize('P') * 8)" 🙂

[behackl]

@behackl Maybe you accidentally have a 32 bit python for it to try compile scipy from source? seems to be the only major ones misssing on pypi, you can check by running python3 -c "import struct; print(struct.calcsize('P') * 8)" 🙂

My local issue is due to tooling (and mostly my own fault): I'm using uv and have locally declared the additional dependencies as dev-dependencies. I've had to bump the required version of Python to 3.9 (otherwise Sphinx~=7.2.6 is refusing to install). With python >= 3.9 the latest version of scipy that I can install is 1.13.1, for which there are no wheels for Python 3.13.

The incompatible version of sphinx that is declared by the project should perhaps be fixed, but otherwise all of this is just a (somewhat) self-made inconvenience. :-)

[Tremeschin]

Ah, I was using good old python -m venv and pip install .[dev], your last comment does indeed happen when using uv to manage the venv, just tried it here, very similar stuff. But I digress to the main topic, as we're talking tooling 😄

[einarf]

There are definitely some quirks still in uv especially related to dev tools vs the actual dependencies for the package itself. We had a problem with this in arcade were some sphinx related tools requires 3.10+ while the package is 3.9+. uv didn't like that!

Anyway. I loosened the requirements completely on numpy now in master branch (currently 3.0). Once I've upgraded a few more things and fixed some bugs there will be a new release.