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

Packaging python metadata for downstream #493

Open
LecrisUT opened this issue Apr 19, 2024 · 5 comments
Open

Packaging python metadata for downstream #493

LecrisUT opened this issue Apr 19, 2024 · 5 comments

Comments

@LecrisUT
Copy link

In Fedora many of the dependencies are auto-detected via %pyproject_buildrequires and sometimes cmake pinning is included in a projects [build-system].

Just to make such packaging smoother it would be nice to have a way to generate only the python metadata (and python-only files) so that can be packaged in cmake. This most likely would require revisiting scikit-build-cli.

On this repo side, there is only 1 requirement, to make sure release candidate are tagged and released close to the release of cmake upstream.

@henryiii
Copy link
Contributor

henryiii commented Jun 26, 2024

The fix is to not add cmake to build-system, and maybe specifically filter 'cmake', 'ninja', 'patchelf', and any other PyPI redistrubtions with the auto-detection tool. They are not meant to be distributed outside of PyPI.

Duplicate of #80 and others, though this is more focused on redistributors, which would keep the versions in sync, at least. See my comment on #511.

One other problem with providing these metadata files is that it can cause some systems to add a Python dependency when one isn't needed (Conda-forge's ninja and cmake packages would then require Python, while they don't now), and it can also tie this to one version of Python (it would in Homebrew), when cmake and ninja do not require Python.

@LecrisUT
Copy link
Author

Beyond the build-system, my worry is if the python files gain more functionalities like #36 such that it is used beyond the building of python packages.

One other problem with providing these metadata files is that it can cause some systems to add a Python dependency when one isn't needed

Oh good point. On distro packages it is possible to tune the dependencies of each sub-package. I guess you can mimic that behavior by splitting the packages, but that would lead desyncing and other issues.

@henryiii
Copy link
Contributor

Additional functionally will not be added to this package. Scikit-build-core or other packages support additional functionality. This is only a redistribution.

@LecrisUT
Copy link
Author

Ok, that's reassuring. Could the relevant feature requests be closed?

@LecrisUT
Copy link
Author

Also, maybe adding some notes/warning on the README such that people do not start using/relying on the python files here, and instead use other tools that check the availability of system cmake first

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