Skip to content

Draft: Port to uv + scikit core build#170

Open
rpep wants to merge 7 commits intomasterfrom
port-to-uv-scikit-core-build
Open

Draft: Port to uv + scikit core build#170
rpep wants to merge 7 commits intomasterfrom
port-to-uv-scikit-core-build

Conversation

@rpep
Copy link
Member

@rpep rpep commented Feb 8, 2026

Depends on other PR

@rpep
Copy link
Member Author

rpep commented Feb 8, 2026

@davidcortesortuno This moves away from setup.py to more modern way of building Python packages - fully pyproject.toml-able, no Python code executed during build.

@rpep
Copy link
Member Author

rpep commented Feb 8, 2026

@davidcortesortuno still need to fix the Docker builds.

@davidcortesortuno
Copy link
Collaborator

I really like the idea of moving to uv, but the build process for the cython extensions looks more complicated than using setup.py now. Do you think it's better to use Cmake in terms of maintainability?

@rpep
Copy link
Member Author

rpep commented Feb 13, 2026

@davidcortesortuno it's just become more standard unfortunately/fortunately depending on your perspective. The plus side is that by using standard FindX stuff in CMake it can hook into pkgconfig and find the libraries using stnadard methods for Linux. It's more familiar for packagers. I was looking at trying to get Fidimag into Spack https://spack.io/ and with this sort of setup it's all quite easy as it's a well trodden route.

The main thing is that setup.py is now not seen as a good option; people don't want to run arbitrary Python code at pip install time. CMake is also significantly better at handling different compilers and toolchians than our hacked-together setup was.

If you try this (obviously you need CMake installed) you see that it'll recompile automatically on change too, it's quite seamless.

@davidcortesortuno
Copy link
Collaborator

Fair enough. I was also thinking if we should move away from Cython as well, in favour of something like nanobind, since most of the Cython code is just wrappers to call pure C functions, with loads of repeated function headers (instead of using pure Cython)

I recently saw that Sundials 7.6 started to provide experimental official Python bindings https://sundials.readthedocs.io/en/latest/Python/Usage.html This would allow us to drop our sundials pyx file. Since you already updated Sundials to the latest version I recommend we should try it. I guess this will ease the compilation part of the modules

@rpep
Copy link
Member Author

rpep commented Feb 16, 2026

PyBind11 is very popular but I've never tried it personally. I'm not sure the Cython stuff matters given the overhead of calls will be tiny compared to the C function calls.

@rpep
Copy link
Member Author

rpep commented Feb 16, 2026

Re: Sundials Python bindings - maybe as another stage after this? Don't want the PR to grow much more :D

@davidcortesortuno
Copy link
Collaborator

Re: Sundials Python bindings - maybe as another stage after this? Don't want the PR to grow much more :D

Sure!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants