[Feature Suggestion] Python bindings for cmake

[Andersama]

I'm not a python developer, but recently in writing some scripts for a cmake integration into an editor I found this module, however it uses the same mechanism I already was using. Namely by opening a shell via the subprocess module. In testing even with a shorter command like passing --version to cmake, I found there's roughly a ~.1+ second latency while python does the work to open a shell.
Meanwhile with another module which had python bindings there was no such latency (because it's roughly like a function call).

My suggestion, propose actual python bindings to be built into the cmake binary so that you can tap into it via this module, and where possible write a guide how to follow the ide integration guide via python, this way people looking to integrate cmake don't have to reimplement parsing different cmake related json, txt and cache files by hand.

[henryiii]

The fix for this is simple, and I'd like to try it after #312 - we should put cmake in the scripts dir, and then (the tricky part) make the python library find it from there. And make sure it can find its data files. If we can do that, then there wouldn't be an added Python latency, and it would behave exactly correct in all situations.

[jcfr]

in the scripts dir

That makes sense: That would then be Scripts on Windows, and bin on unix. Is there a variable describing this location ?

make the python library find it from there

Since it would be in the PATH, wouldn't that work without doing any thing special ?

[henryiii]

Is there a variable describing this location?

There's a special folder in the wheel (the bin folder) that gets unpacked to the correct place. In scikit-build-core, it's ${SKBUILD_BIN_DIR}.

Since it would be in the PATH

You don't have to activate a virtual environment. .venv/bin/python -m "import cmake; ..." should continue to work. I think you can get the location of the installed binary, though, IIRC with importlib-metadata.