This is a big change but the two things benefit each other. Historically, pyquante2 has been fussy with source installation and identifying which Python/Cython versions work. With GitHub-based CI this is no longer a problem.
There also used to be an issue where setup.py was not self-contained because you couldn't declare build dependencies in a single file. The build-system.requires in pyproject.toml solves that problem. Originally I had cython<3 in there as well, because a bigger ask when building from source is providing a compiler and not Cython, but I think compiling with MSVC should be fixed first (https://github.com/berquist/pyquante2/actions/runs/6740885249/job/18324625541). Yes, GitHub provides Windows runners with compilers and Cython on Windows should work in the future.
Do you know why the Becke code doesn't have a C file committed?
In the future CI can be extended to packaging, but that's too much for a single PR.
This is a big change but the two things benefit each other. Historically, pyquante2 has been fussy with source installation and identifying which Python/Cython versions work. With GitHub-based CI this is no longer a problem.
There also used to be an issue where
setup.py
was not self-contained because you couldn't declare build dependencies in a single file. Thebuild-system.requires
inpyproject.toml
solves that problem. Originally I hadcython<3
in there as well, because a bigger ask when building from source is providing a compiler and not Cython, but I think compiling with MSVC should be fixed first (https://github.com/berquist/pyquante2/actions/runs/6740885249/job/18324625541). Yes, GitHub provides Windows runners with compilers and Cython on Windows should work in the future.Do you know why the Becke code doesn't have a C file committed?
In the future CI can be extended to packaging, but that's too much for a single PR.