-
Notifications
You must be signed in to change notification settings - Fork 191
Move metadata from setup.py
to pyproject.toml
and build retworkx
in a separate setup.py
#1419
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
I confirmed that the generated metadata in the wheel is correct: https://gist.github.com/IvanIsCoding/135b258198742f49111736ab537b2729 I just need to investigate why the coverage test failed and then this should be good to go. Edit: setuptools need to be slightly newer than the default that ships with 3.10; still, our rustc is newer than that; after coveralls comes back from maintenance we should be able to merge |
Qiskit/qiskit#10958, Qiskit did this a while ago. Although for the Rust part we are moving it to |
Pull Request Test Coverage Report for Build 14787409875Details
💛 - Coveralls |
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.
Overall I like the change here I had a couple of questions inline but nothing major.
My biggest concern is over the retworkx shim removal. I had originally planned (and think we might have documented at the time) that we'd drop the shim in rustworkx 1.0. Personally I'm actually fine if we wanted to take this as the indication that the next release is 1.0 even if it leads to longer baking time until we release. I think we've basically been treating things like we're already committed to api compatibility in that way already so it's more taking the opportunity to clean up any interfaces.
I am also thinking we might want to do one final retworkx release first though, that says it is retired. Right now we say:
retworkx is the deprecated package name for rustworkx. If you're using the retworkx package (either as a requirement or an import) this should be updated to use rustworkx instead. In the future only the rustworkx name will be supported.
We could make that a bit more definitive and say retworkx is the former name and it is not supported any longer, rustworkx should be used instead.
I might hold on the
Thay way, we can give a final notice to |
I have an idea on how to make this work. We'll need to move |
Minor update, but I read https://www.reddit.com/r/Python/comments/1jwbymm/psa_you_should_remove_wheel_from_your/ so I discovered:
|
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.
Thanks for the updates, overall this is looking quite good now. I left some inline suggestions to add the linting for retworkx back. Until we release 0.17.0 we should still be running those in the remote chance there is a change made to the code there. I think it's good to merge now.
The only open question I have is did you validate the wheel and release jobs still function correctly? I don't expect any hiccups but for a change like this it's good to validate we're still building the release artifacts without issues.
@@ -202,12 +202,10 @@ jobs: | |||
- name: Install deps | |||
run: pip install -U setuptools-rust wheel build | |||
- name: Build sdist |
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're actually not building an sdist here not that it matters. Apparently we're only uploading a wheel for retworkx.
I will address the comments but regarding:
I built the wheel locally. Overall, the tests and specially the coverage test validate the wheel is valid. My biggest fear was the METADATA, but the links I posted above for the gist seem to identicate that gets included as well. For wheels build, after I address all comments I will try to kick cibuildwheel. From inspecting how cibuildwheel, apart from retworkx, nothing should change. For |
Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Test run: https://github.com/IvanIsCoding/rustworkx/actions/runs/14553292059 I excluded macOS, PowerPC64, and s390x as those are more expensive for me to test on my personal project. But if Linux builds I think it should be all good. Windows is a bonus. |
@mtreinish there's a spurious failure from x86_64 I am retrying (rustup failed to install, unrelated) but we got some wheels in the first attempt. They look correct to me. I think this is good to go. edit: I opened #1432 but it is completely unrelated |
…` in a separate `setup.py` (Qiskit#1419) * Modernize setup.py * Farewell to retworkx * Add release note about retworkx removal * Move even more data to pyproject.toml * PEP 639 says this is deprecated * Add dependency groups later * Move even from setup.py to pyproject.toml * Migrate all setup.py to pyproject.toml * Move nox dependencies to pyproject.toml * Document new way to do debug builds now that we no longer use setup.py * Better way to phrase the documentation * Remove duplicate section * Try updating setuptools for coverage job * Add docs dependency group as well * Make description the same as the paper * Revert retworkx code * Say this will be the last retworkx release * Trying to make retworkx work * retworkx has its own setup.py * Account for new directory when publishing * Document setuptools-rust * Edit message saying it is the final release * sunset -> retired * Endline * Ensure setuptools-rust is up-to-date * Use setuptools>=70.1.0 and remove wheel * Apply suggestions from code review Co-authored-by: Matthew Treinish <mtreinish@kortar.org> * Black --------- Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
I am removingretworkx
, it has been more than one year since it was deprecated in #1004. This totals 2 years since the project changed names.I am also profiting to embrace
pyproject.toml
more. This is motivated by #1416, in general the prospect for most projects is to consolidate most data inpyproject.toml
.edit: we set this release as the last one depending on
rustworkx
, I had to use a separatesetup.py
file for this. In short, theretworkx
code now is nested in a folder. We havesetup.py
that reads from our ownpyproject.toml
in the root. The code is now inretworkx/retworkx
given the new folder setup.