-
-
Notifications
You must be signed in to change notification settings - Fork 26k
BLD Remove support for setuptools build #29400
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
Conversation
def gen_from_templates(templates): | ||
"""Generate cython files from a list of templates""" | ||
# Lazy import because cython is not a runtime dependency. | ||
from Cython import Tempita | ||
|
||
for template in templates: | ||
outfile = template.replace(".tp", "") | ||
|
||
# if the template is not updated, no need to output the cython file | ||
if not ( | ||
os.path.exists(outfile) | ||
and os.stat(template).st_mtime < os.stat(outfile).st_mtime | ||
): | ||
with open(template, "r") as f: | ||
tmpl = f.read() | ||
|
||
tmpl_ = Tempita.sub(tmpl) | ||
|
||
warn_msg = ( | ||
"# WARNING: Do not edit this file directly.\n" | ||
f"# It is automatically generated from {template!r}.\n" | ||
"# Changes must be made there.\n\n" | ||
) | ||
|
||
with open(outfile, "w") as f: | ||
f.write(warn_msg) | ||
f.write(tmpl_) |
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.
meson generates the cython files from tempita templates automatically ?
Is there a way to have this warning in the generated files with meson ?
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.
we have a script that has similar logic and is used in meson.build
files https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/_build_utils/tempita.py. It was strongly inspired from Numpy and Scipy.
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.
We could have the warning if we really insist but the .c
files are out of tree (build/<something>
by default) in general they are in some deeply nested subfolder so I would argue it is a lot less tempting to modify them compared to the in-tree situation before?
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.
but the .c files are out of tree
I was more worried about the .pxd
and .pyx
generated files, but the fact that it's out of tree should prevent any direct edit of these files. So the current situation is fine to me
sklearn/_build_utils/__init__.py
Outdated
""" | ||
Utilities useful during the build. | ||
""" |
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 you can just remove the full _build_utils
folder at once since there's nothing left besides this docstring
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.
never mind there are other files...
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 removed the docstring but there are stuff that are used e.g. https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/_build_utils/tempita.py https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/_build_utils/version.py. To be honest not sure why they are under sklearn
since it feels like maybe they don't have to be? I mirrored Numpy and Scipy here.
Edit: maybe there is a use case when installing from sdist, not sure ...
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.
Yeah you can ignore this comment, I thought you were removing all files and content from this folder, but realized afterward that there are other files left.
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.
Edit: maybe there is a use case when installing from sdist, not sure ...
Not actionable for this PR: I can not think of a good reason for having them under sklearn
. _build_utils
can be in the sdist
at the root level.
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.
Yep I kind of agree ...
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.
LGTM once the lock files have been regenerated after a merge with main
.
build_tools/azure/install.sh
Outdated
# TODO temporary hack while waiting for version checks inside meson.build | ||
# if [[ "$DISTRIB" == "ubuntu" || "$DISTRIB" == "debian-32" ]]; then | ||
# ADDITIONAL_PIP_OPTIONS="$ADDITIONAL_PIP_OPTIONS --check-build-dependencies" | ||
# fi |
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 don't understand the TODO comment: it's a temporary hack but actually it's commented out. Do you mean that we we would like to pass --check-build-dependencies
but it's not possible because of a limitation of meson.build
?
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.
Good point I forgot this, let me fix this.
Basically what happens following the Debian 32 bit Docker image update:
pip
is recent enough to have--check-build-dependencies
- system numpy is too old (1.24) to satisfy the
pyproject.toml
build dependencies (numpy>=1.25) so usingpip install --check-build-dependencies
will result in an error
Previously (before the Debian 32 bit Docker image update), pip
was too old to have --check-build-dependencies
flag ...
The temporary hack was to never add --check-build-dependencies
as it will be removed in #28721 anyway. I can do a bit less hacky I think.
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 ended up removing this since there is no need to use --check-build-dependencies
in the CI. This was mostly intended to have user friendly error when your build dependencies are not recent enough but it has limitation and #28721 will remove --check-build-dependencies
everywhere soonish.
…nto remove-setup-py
dotting the i's and crossing the t's Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>
…as this will go away with scikit-learn#28721
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.
LGTM
Merging my own PR with 3 approvals. Bye bye setuptools! |
Close #29346
Fix #29302
Comments:
pip
does not know how to deal with apyproject.toml
without asetup.py
(ah the good old days 🙃)