SKBUILD_DATA_DIR install destination results in an absolute _IMPORT_PREFIX

[psalvaggio]

Use Case:

I am building a project that I want to install into a conda environment. I want all my package artifacts to go into lib/python3.X/site-packages/${PROJECT_NAME}, but the installed CMake config to go into $CONDA_PREFIX/lib/cmake, so that when the conda environment is active, find_package can find my package with no additional configuration (via the PATH logic in find_package).

Issue:

I install the CMake config via:

set(DST "${SKBUILD_DATA_DIR}/lib/cmake/${PROJECT_NAME}")

install(
  EXPORT <my-export-set>
  NAMESPACE ${PROJECT_NAME}::
  DESTINATION "${DST}"
)

write_basic_package_version_file(
  ${PROJECT_BINARY_DIR}/${PROJECT_NAME}-config-version.cmake
  VERSION ${PROJECT_VERSION}
  COMPATIBILITY SameMajorVersion
)

configure_package_config_file(
  config.cmake.in
  "${PROJECT_BINARY_DIR}/${PROJECT_NAME}-config.cmake"
  INSTALL_DESTINATION "${DST}"
)

install(
  FILES
    "${PROJECT_BINARY_DIR}/${PROJECT_NAME}-config-version.cmake"
    "${PROJECT_BINARY_DIR}/${PROJECT_NAME}-config.cmake"
  DESTINATION"${DST}"
)

when I look at the resulting ${PROJECT_NAME}-targets.cmake file, I get the following _IMPORT_PREFIX:

set(_IMPORT_PREFIX "/tmp/tmpzj5dlyy6/wheel/platlib/<my-project>")

This results in non-relocatable install.

Is it possible to get _IMPORT_PREFIX to get set to a relative path to the root of the venv or ${platlib}/${wheel.install-dir}?

[LecrisUT]

Hmm this would be tricky because scikit-build-core would have to be made aware of the installation paths that are to be used outside of the site-packages and afaik it cannot perform the install itself in that case.

One alternative is that you can write the lib/cmake etc. files under site-packages/${PROJECT_NAME}, and in the pyporject.toml you can add an project.entry-points."cmake.prefix" pointing it to ${PROJECT_NAME} thus all pythonic projects would be able to detect it. scikit-build-core automatically adds site-packages to the CMAKE_PREFIX_PATH but I'm not sure if conda can also do this.

Another design you can consider is breaking up your project into a main project and python bindings, the former containing CMake import files, and the latter working either through add_subdirectory from the main project or find_package. I have a project that is designed like that spglib/spglib#520. In the context of PyPI packaging it would use add_subdirectory and install everything under the site-packages/${PROJECT_NAME}, but in the context of conda, you would have to first install the main project without the python bindings, and then do the python binding installation pulling in from the previous installation.

[psalvaggio]

Thanks for the suggestions, I'll try some options out and see what works best for my situation.

In terms of making scikit-build-core aware of installation paths, I do know that the CMake file-based API https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html can be used to interrogate installation paths. I don't know if that would help with this issue specifically, but I thought I'd mention it.

[LecrisUT]

In terms of making scikit-build-core aware of installation paths, I do know that the CMake file-based API https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html can be used to interrogate installation paths. I don't know if that would help with this issue specifically, but I thought I'd mention it.

I think the issue is a bit more fundamental in that the python installation goes through the .whl archive creation and decompressing in the relevant site-packages folder, and you wouldn't be able to have a file pointing to an absolute path in there. Of course you could install to an absolute path as part of you CMake script, but that would break relocality and the Config.cmake files would be a bit wonky about that. With respect to conda installs it is even worse because the $CONDA_PREFIX is "relocatable" so the absolute path created for the conda package there would again break things.

[henryiii]

You can't have a relative link between site-packages and the data folder. It depends on when the wheel is unpacked, and can't be pre-computed when making the wheel. Is that what you are trying to do, or do you want everything to be inside the data folder? That should be possible.

[psalvaggio]

Yes, I was trying to split things between site-packages and the venv root, with my installed CMake config files living in $CONDA_PREFIX/lib/cmake and the rest of my artifacts living in site-packages. If that's not possible, as it seems like it is not, we can close this and one of the suggestions @LecrisUT laid out is likely to work if I redesign a bit.