cmake_with_sdist equivalent in scikit-build-core #392
Comments
|
See #319 (which is about the backward compat option, but I'd expect a pyproject.toml equivalent to be available about the same time), also #249, which discusses the need. I think the main issue is coming up with a good design. Would love as many examples of usages of this as possible, I only have two so far (in #319). I don't have custom variables to indicate what state scikit-build-core is in, but that's a good idea. You could also detect wheel vs. metadata preparation vs. editable install with a variable like that. |
|
Cool to hear. I think variables like |
|
Do you have a pre-switch example? I'd like to have examples of what this looks like in practice to have a good idea of what to design. I'd probably go with |
|
Here: This is a custom sdist command with scikit-build. Would like to do that downloading in CMake. PS: |
|
FWIU, that's not actually running CMake when making the SDist, but downloading a tarball? Ahh, yes, "Would like to do that downloading in CMake". FWIW, you can do this with git submodules today with scikit-build-core. Okay, thanks, good to have a data point. |
See #392 (comment). --------- Signed-off-by: Henry Schreiner <[email protected]>
|
git submodules is of course an option, but we are relying on CPM.cmake, so I think knowing the skbuild-state is sdist to copy the downloaded folder could be convenient. |
|
Is the issue that skbuild does not run cmake before sdist creation? Otherwise it should be possible with a combination of setting the cmake source location and sdist.include option right? |
|
Currently CMake does not run (and isn't even required) when making an SDist. It's only run for the wheel step. The tricky part here is figuring out what you'd do with CMake during the SDist step. You don't want the config output build directory in the SDist, but you do want the downloaded packages (which are in the build directory as output...) Examples I see of this currently with scikit-build (classic) generally have a lot of python dedicated to copying in an overloaded sdist command. |
|
For CPM.cmake, maybe we could integrate with them, and their CMake files could be even distributed in a package. Maybe we should target solving that specific case first, then a more general solution might be more obvious. |
|
The download location is configurable via a cache variable |
|
Hmm, we could save I'd also want to avoid saving the config output of the fetch content, as the environment when making the SDist is not the environment when making the wheel. |
|
Why not have the user setup dedicated folder in the source directory? That way it does not have to be relocated, and if the setting is in pyproject.toml, then it is reproducible at the wheel stage without internet connection. The folder structure might end up a bit weird, but that can be corrected by setting |
|
It won't ever be a default since we won't ever default to running cmake when making an SDist. :) Making it too automatic, even when enabling CMake during the SDist step, might be something to keep in mind as possibly undesirable, though. We may want to implement hatchling-style force-include first, that likely would be handy for this (as long as there was some way to point at the build directory). Actually, I wonder if force-include + running cmake in the SDist step would be enough? I guess it would need to go both directions... Okay, maybe |
|
👍 on that approach, except for
The cmake author can and should setup the Mapping it to and from the build directory is a bit non-standard and confusing as to which option is relative to build, which one is relative to source. And it avoids having to do the reverse of copying from the sdist to the build directory. |
|
It can't be done "without explicit configuration", since anything gitiginored will also be excluded by the SDist unless you explicitly include it in your configuration. But that sounds like a good plan, and is the simplest to implement on our side. |
For CPM I wouldn't hijack So for CPM this should be solved with the information For then using this local folder with CPM, see here: cpm-cmake/CPM.cmake#483 |
Could you elaborate on that? Is your package such that the main cmake files (that would be used downstream) is from [tool.scikit-build.cmake.define]
CPM_SOURCE_CACHE = "third_party"Sidenote: downstream should not be using upstream's cpm imo because it does not the same overwriteability that |
|
@ LecrisUT Maybe you are right. But I guess I would set So for me this would be solved by being able to run the cmake configure stage when building sdist. |
Working on #392. - [x] Add to setuptools build_meta, too For later PR: ```diff + libpl = sysconfig.get_config_var("LIBPL") + library = sysconfig.get_config_var("LIBRARY") + + if libpl and library and Path(libpl).joinpath(library).is_file(): + assert isinstance(libpl, str) + assert isinstance(library, str) + return Path(libpl) / library ``` Signed-off-by: Henry Schreiner <[email protected]>
|
Done in #454. |
|
@henryiii for the record: Works like a charm! 🎉 https://github.com/mhm-ufz/mHM/blob/ac5d5f74cbfe693bbdee487afcf6202d0074c83a/pyproject.toml#L107 |
Is there something similar to the legacy
cmake_with_sdistin scikit-build-core (beside the setuptools backend)?An if so (or if planed), is there a CMake variable to indicate we are currently building sdist?
Cheers,
Sebastian
The text was updated successfully, but these errors were encountered: