-
Notifications
You must be signed in to change notification settings - Fork 31
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
chore(build): move to scikitbuild-core #312
Conversation
f9ddf79
to
a17ec66
Compare
pyproject.toml
Outdated
|
||
[project] | ||
name = "cmake" | ||
version = "0.0.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess dynamic versions are for the future ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty low priority for now, as it adds significant extra complication for very little benefit for now. Eventually will probably add support for reading from a regex & setuptools_scm.
"Topic :: Software Development :: Build Tools", | ||
"Typing :: Typed" | ||
] | ||
requires-python = ">=3.7" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a showstopper (for now) for this project ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scikit-build/scikit-build-core#39 is needed. It won't ever build from SDist on Python <3.7, but don't think that's a big deal at this point.
Ideally we can just set a configuration parameter to tell it we don't depend on Python, and it will produce py2.py3
wheels automatically. Maybe it could even be smart enough to check the output binaries, and report if they depend on Python (normal or ABI3), or don't? (It's important to answer that question for the extensionlib work too).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scikit-build/scikit-build-core#39 is needed
It would be nice to have it but it's not needed. It would allow to get rid of all the specific repair scripts in the repo.
It won't ever build from SDist on Python <3.7, but don't think that's a big deal at this point.
I'm a bit more hesitant on "runs everywhere", "need >= 3.7 to build from sdist". In the end, it will be ok but might be a bit too soon ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we build from SDist, I think it's already much slower, more likely to fail, etc - it's really supposed to be a wheel distribution. So not supporting building from SDist on <=3.6 doesn't seem too bad. And a user can always either use Python 3.7+ to build a wheel then install it on 2.7-3.6, or use an older version.
EDIT: this was due to scikit-build/ninja-python-distributions#157 |
I'll investigate more, though a quick thought: build's output is better (it lets you know the packages it's trying to install each step), maybe that could be swapped out for pip? Maybe even build the wheel then use |
I'm providing a way to set logging level in the next version (scikit-build/scikit-build-core#40), I can add some extra logging to see why it can't import Ninja. Maybe it's not adding ninja even though it's not present? |
Thanks @henryiii, so the whole mess with sdist was linked to the broken ninja package in the end. |
the macOS wheel has a |
492ddfa
to
2096e2f
Compare
FYI, @agoose77, I think the reproducible SDists feature is breaking this CMake test:
|
@henryiii it looks like it might not be the reproducibility patch; the CI still fails in the same place as far as I can see. |
85d8773
to
79b125d
Compare
The commit right before the repro patch works. Tomorrow I'll try the commit after. Not totally sure why changing the SDist would break the wheel tests... Edit, no, wait, I think a few failed. I'll check tomorrow. e4ed476a77b13d36379ed7e2ba52496cfcd00c4b (61) Fails. It was the make fallback. One test fails if it falls back on make. |
Update pyproject.toml Apply suggestions from code review Update pyproject.toml WIP: try branch of skbc Update pyproject.toml WIP: right before repro builds Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com> Update pyproject.toml
3e20e0b
to
8ae0687
Compare
name looks right. :) |
* master: (112 commits) docs: fix up docs (scikit-build#454) chore(deps): update pre-commit hooks (scikit-build#443) chore(deps): bump cmake from 3.28.1 to 3.28.3 (scikit-build#452) chore(deps): bump the actions group with 1 update (scikit-build#453) Update to CMake 3.28.3 (scikit-build#450) chore(ci): use 4 threads to compile on GHA (scikit-build#449) Update to OpenSSL 3.0.13 (scikit-build#448) chore(deps): bump the actions group with 1 update (scikit-build#447) chore(deps): update pre-commit hooks (scikit-build#441) ci: group dependabot updates (scikit-build#442) chore(deps): bump cmake from 3.27.9 to 3.28.1 (scikit-build#440) Update to CMake 3.28.1 (scikit-build#439) ci: support artifact v4 (scikit-build#438) chore(deps): bump actions/upload-artifact from 3 to 4 chore(deps): bump actions/download-artifact from 3 to 4 Update to CMake 3.28.0 chore(deps): update pre-commit hooks chore(deps): bump actions/setup-python from 4 to 5 (scikit-build#431) chore(deps): bump cmake from 3.27.7 to 3.27.9 (scikit-build#430) Update to CMake 3.27.9 (scikit-build#429) ...
f4a17c3
to
a232567
Compare
Test command is already specified in pyproject.toml
From scikit-build#312 (comment) > If we build from SDist, I think it's already much slower, more likely > to fail, etc - it's really supposed to be a wheel distribution. So not > supporting building from SDist on <=3.6 doesn't seem too bad. And a user > can always either use Python 3.7+ to build a wheel then install it on > 2.7-3.6, or use an older version.
…ualenv The use of the `virtualenv` pytest fixture become obsolete following commit 280260d ("chore(ci): bump `test_sdist` python from 3.11 to 3.12 (scikit-build#423)", 2023-12-02)
518334b
to
ebedcde
Compare
ebedcde
to
641b738
Compare
metadata.version.provider = "scikit_build_core.metadata.setuptools_scm" | ||
ninja.make-fallback = false | ||
sdist.include = ["src/cmake/_version.py"] | ||
wheel.py-api = "py2.py3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not in line with requires-python = ">=3.7"
and I think pip will not install the wheel from PyPI when running python 2.7/3.6.
Can/Shall we drop/update the requires-python
?
If we still support 2.7/3.6 then they shall still be tested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python 2.7 & 3.5 can't use the wheel produced. I'm checking what can be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened #455 depending on python<3.7 support requirement (for wheels).
Closing. Superseded by #455 |
@henryiii, just a draft to follow progress with scikitbuild-core. You're obviously well aware of what happens there but I wanted to give it a try already.