`wheel.packages` cannot point to a module?

[LecrisUT]

I've encountered this when trying to write a minimal test setup where I didn't care about placing everything in a proper package, but wanted to write them dirty as modules, i.e.:

$ tree
.
├── CMakeLists.txt
├── hello.py
├── main.cpp -> ../main.cpp
└── pyproject.toml

[build-system]
requires = ["scikit-build-core", "main-project-that-i-am-testing-the-packaging-for"]
build-backend = "scikit_build_core.build"

[project]
name = "simple-test-for-the-CMake-find_package"
version = "0.0.0"

[project.scripts]
run_test = "hello:run"

[tool.scikit-build]
wheel.install-dir = "simple_test"
wheel.packages = ["hello"]

And in the test I want to simply run the executable. I would probably remove the wheel.install-dir so that it installs directly into SKBUILD_SCRIPTS_DIR, but just a weird setup where I got this to break :shrug:

[henryiii]

Hmm, no, it's only directories (packages). If all it is is a wrapper, you should install to SKBUILD_SCRIPTS_DIR (you need to use experimental=True + wheel.install-dir = "/scripts" or install to SKBUILD_SCRIPTS_DIR, though). I've wondered in the past if we could set the bin install dir for users but we don't currently.

[LecrisUT]

Hitting this one again because setting ${SKBUILD_SCRIPTS_DIR} breaks the install(TARGETS EXPORT). For unix, isn't the bin directory relative path is known and in the same prefix as lib(64)/python/site-packages? I'm not sure if the same is true for windows though. I'm wondering if we can manipulate configure_package_config_file(INSTALL_DESTINATION) or some other property in order to minimize the changes of the default GNUInstallDirs setup.