Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating scikit-build to scikit-build-core? #1674

Open
tjni opened this issue Aug 3, 2023 · 1 comment
Open

Migrating scikit-build to scikit-build-core? #1674

tjni opened this issue Aug 3, 2023 · 1 comment

Comments

@tjni
Copy link

tjni commented Aug 3, 2023

Hi team,

What is the temperature for migrating from scikit-build to scikit-build-core? The README of scikit-build says:

The next generation of scikit-build, scikit-build-core, is currently under development. This provides a simple, reliable build backend for CMake that does not use setuptools and provides a lot of new features. Scikit-build-core can also power a setuptools-based extension system, which will eventually become the backend for scikit-build (classic). If you do not require extensive customization of the build process, you should consider trying scikit-build-core instead of scikit-build.

My desire from this stems from improving the packaging of this package in nixpkgs, where our need is to use system provided CMake and Ninja instead of those packages on PyPI. In scikit-build, one must specify a build-time dependency on those PyPI packages in pyproject.toml, which this project has done. However, scikit-build-core provides its own PEP 517 build backend, which therefore can detect if system CMake and Ninja are available and only fall back to the PyPI packages if they are missing.

I would be willing to work on this and submit a PR if folks agree.

@skef
Copy link
Collaborator

skef commented Nov 5, 2023

The current develop branch of afdko has an unusual structure (given the non-standard way it adds C binaries to the path.

We have a branch currently called addfeatures that we will likely merge into develop sometime in the upcoming year. It almost a complete re-write and port of most of our C code into C++, and has a different organization and calling conventions. Anyway, since I ran into some build problems there I decided to port that branch to a pyproject.toml, scikit-build-core-based build. It works well!

My sense is that it would be overly disruptive to back-port those changes to develop early, as it will be easier for down-stream consumers to absorb all the upcoming changes in one go with some advance warning rather than piecemeal. So this fix will get out into the world when we do that switch.

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

No branches or pull requests

2 participants