-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Start transitioning to pyproject.toml #23829
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
3fe5d58
to
9b87d69
Compare
More issues: Not building on min-version
No C coverage:
|
pyproject.toml
Outdated
] | ||
|
||
[build-system] | ||
requires = ["setuptools>=45", "setuptools_scm[toml]>=7", "wheel", "certifi>=2020.06.20", "numpy>=1.19"] |
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 should be oldest-supported-numpy
, see https://github.com/scipy/oldest-supported-numpy
The problem is that if you put a floor here, then when the background env gets made it will pull the newest version of numpy it can find. Numpy promises that things complied with old numpy will work with new numpy at runmtime, but they do not promise that things compiled with new numpy will work with old numpy at runtime.
requires = ["setuptools>=45", "setuptools_scm[toml]>=7", "wheel", "certifi>=2020.06.20", "numpy>=1.19"] | |
requires = ["setuptools>=45", "setuptools_scm[toml]>=7", "wheel", "certifi>=2020.06.20", "oldest-supported-numpy"] |
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.
Now it seems like the following happens:
xarray 2022.6.0 requires numpy>=1.19, but you have numpy 1.17.3 which is incompatible.
pandas 1.4.4 requires numpy>=1.18.5; platform_machine != "aarch64" and platform_machine != "arm64" and python_version < "3.10", but you have numpy 1.17.3 which is incompatible.
60890cd
to
8ada724
Compare
In the long run, when all the C/C++ extensions are wrapped using We might have to be careful with the |
New error in some builds:
|
It is probably worth rebasing this on |
17800b5
to
f650809
Compare
Looks surprisingly promising. Wouldn't trust it even if everything happens to pass though (hasn't happened yet). For example, I do not really know how to deal with the namespace package thing (not what it actually is). |
"pillow>=6.2.0", | ||
"pyparsing>=2.2.1", | ||
"python-dateutil>=2.7", | ||
"setuptools_scm>=7.0" |
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 should be conditional, but I have not found any info how to do this dynamically.
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 think it is needed at all as it is in the [build-system] requires
section. It is needed by anyone who uses --no-build-isolation
in their pip install .
, but in that situation they will need to have preinstalled all of the [build-system] requires
packages to proceed.
Although I might be missing some other use of setuptools_scm
in testing or somewhere else?
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.
It was added as someone had problems running tests in a particular setup(?).
Without it, this breaks in the tests:
matplotlib/lib/matplotlib/__init__.py
Lines 171 to 180 in 007c4c1
if ((root / ".matplotlib-repo").exists() | |
and (root / ".git").exists() | |
and not (root / ".git/shallow").exists()): | |
import setuptools_scm | |
return setuptools_scm.get_version( | |
root=root, | |
version_scheme="release-branch-semver", | |
local_scheme="node-and-date", | |
fallback_version=_version.version, | |
) |
although it indeed is not really required for a user install.
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 see now. So it shouldn't be in the dependencies
section of the pyproject.toml
as then wheel users will be forced to have it which means it should be in one of the requirements files instead, perhaps requirements/testing/all.txt
?
Eventually I would expect the requirements files to be replaced with [project.optional-dependencies]
sections in the pyproject.toml
, but that is not necessary yet.
Wheels are 37 MB. Probably as the test images are included... |
e921399
to
3d8c9c8
Compare
Push this to mpl 3.8 to avoid any last-minute packaging issues for mpl 3.7. |
@oscargus I've experimented with this locally and I think I have made some progress. If I add this new section to the
then the test images are excluded from the wheel. That might be excluding too much, so if you remove that section (
then only the PNGs and SVGs are excluded. That still might be excluding too many files, but it is a start. |
Thanks @ianthomas23 ! I've updated it and now I think I know how to check the possible problems as well. |
cd84117
to
8b2df24
Compare
We discussed this last week on call; we think it makes sense to start having some kind of |
Feel free to do so! I was trying to learn, and I have learnt, but not sure if my knowledge will be enough to finish it (although the dev-section etc is quite straightforward...). |
PR Summary
Related to #23815
Issues:
Lots of:PR Checklist
Tests and Styling
pytest
passes).flake8-docstrings
and runflake8 --docstring-convention=all
).Documentation
doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).