-
Notifications
You must be signed in to change notification settings - Fork 370
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
BLD: Wheels! #2197
BLD: Wheels! #2197
Conversation
62f96de
to
0625e41
Compare
Alright, GEOS is now gone from Cartopy and we can start building wheels 🚀 This should be ready for review now, and it would be good if someone could look at this and make sure it all makes sense. Maybe pull down this branch and trying building it locally to make sure that the contents of the wheels are what we expect. I am definitely not an expert on build contents. Once this PR goes in, we will need to remove Appveyor from the repository because it appears like it is triggering even without a |
I can’t help with the technical side of this, but it might be good to also update this page. |
@varchasgopalaswamy, thank you for checking!
That version doesn't seem quite right to me. My initial guess is you just haven't pulled down the latest tags? Can you try pulling the remote tags
@rcomer, sure I updated some of that page, let me know what you think of the rewording. |
I found a typo, buy otherwise the rewording looks good to me 😀 |
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.
🎉 Awesome to see this. Overall this seems pretty sensible, though the cibuildwheel stuff was new dark magic to me.
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.
Looks good to me. I'll leave it open for a bit for any comments, but I'm happy to see this go in and get us closer to a 0.22 release.
@greglucas Note there's a conflict now in |
d142c49
to
800d05a
Compare
.github/workflows/release.yml
Outdated
path: ./wheelhouse/*.whl | ||
|
||
build_sdist: | ||
name: Build source distribution |
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 may, as in Matplotlib's current build, want to build sdist first and instruct cibuildwheel
to build out of that.
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'm a bit out of my element here. I tried to do that with a new commit on a separate branch.
https://github.com/greglucas/cartopy/tree/setup-updates-tmp
Failed job: https://github.com/greglucas/cartopy/actions/runs/5601696424/jobs/10245962338
I think it is failing because the sdist isn't being built quite right. It is not cythonizing to convert from .pyx
to .cpp
, where we need to include the .cpp
in the sdist to distribute into the wheel. I'm not sure where we are supposed to build the extension then, do we just call python setup.py build_ext
as a separate step to make sure the .cpp
is created?
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 it is easier for you to take over some of this, feel free to branch off yourself or push directly to my branch. I'm definitely happy to have some help on this.
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.
OK, I think we just needed to call cythonize()
if we are going down the non-sdist route, so I've reworked the logic a bit in setup.py
to try and simplify things a bit more for whether we are in the Cython route or the pre-made cpp route.
Here is a CI run from a separate branch on my fork that demonstrates it working now when building the wheels from the sdist: https://github.com/greglucas/cartopy/actions/runs/5612238838/jobs/10269964395
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.
Maybe this is out of scope for this PR, but any thoughts about using numba to replace the .pyx file?
Upside: No need to compile the .pyx file during build and deal with correctly packaging it. Plus numba has support for automatic parallelization.
Downside: Another dependency.
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.
Definitely out of scope for this PR. If you can show that it is faster than Cython or makes things easier in some way, then a PR would definitely be considered!
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.
As much as I think Numba is cool, it has its own challenges due to its reliance on bridging LLVM and Python. For instance, Numba didn't support Python 3.11 until May 2023, which IMO is unacceptable for something we'd consider as a dependency. I understand the dev team is aware how problematic this is and intends to do better for future releases, but I'd want to see a good track record going forward before we begin to consider that.
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 that we are preparing to build wheels, I wonder if all the work to make Cython optional is all that useful? It was a convenience to not require it, I suppose, but with stuff like build-requires and isolated build venvs and the fact that we're going to make wheels, reducing the need to build from source, maybe that isn't so great as it once was.
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.
Possibly we could take it out... The Cython docs do mention to use an environment variable USE_CYTHON
to control this, so I think we are doing similar to their recommendations. Doesn't hurt to keep it I guess?
https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compilation.html#distributing-cython-modules
1d780c9
to
4475052
Compare
@QuLogic, thanks for the review comments! I think I addressed them all, but let me know if there was anything else I missed. Otherwise, I think it could still use a once-over to see if you spot anything I did odd when making those updates too. |
Simplify some of the setup.py build work now that we have removed more extension libraries. Move the static content over to pyproject.toml and migrate more content to the modern build utilities.
4475052
to
c3ea9f3
Compare
# Only publish on releases | ||
if: github.event_name == 'release' |
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.
Isn't this redundant with the entire workflow's on
trigger? Should that be removed?
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.
You beat me to this :) I was just going to add a comment here indicating I added this. I agree it is the same as the trigger, but this is an extra safeguard that I think is worth it in this case. For example, when I was testing building wheels on my fork, I removed the "on: release", but this would fail because I don't have credentials. However, then I force-pushed to this branch, and all of a sudden triggered this workflow on the PR. I'm not entirely clear it would have gone through the action but it seems prudent to keep to me just to make sure I don't fat finger something again on accident. In the future, we may want to change the trigger to let us trigger it automatically on certain pushes or on request.
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.
PRs shouldn't have any of the credentials/write permissions necessary.
Also, there's no way this workflow as written should be able to trigger on a PR.
That said, there's no harm in being careful.
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 can followup the other questions in other PRs.
This is one fairly large commit on top of the commits removing GEOS in PR #2083.pyproject.toml
file to reduce the size of setup.py and move towards the standardRight now, this is mostly just to demonstrate that we can build wheels (tested the produced artifacts from my fork and seemed to be good from both the sdist and wheels).Closes #2216