Skip to content

Conversation

IvanIsCoding
Copy link
Collaborator

@IvanIsCoding IvanIsCoding commented Aug 13, 2025

Related to #1492

I tested this locally and it worked e.g. python setup.py sdist passes.

For retworkx, it had more to do with the dist being in the wrong path

@IvanIsCoding IvanIsCoding changed the base branch from main to stable/0.17 August 13, 2025 03:30
@IvanIsCoding IvanIsCoding requested a review from mtreinish August 13, 2025 03:30
@@ -42,7 +42,7 @@
long_description_content_type="text/markdown",
author=pyproject["project"]["authors"][0]["name"],
author_email=pyproject["project"]["authors"][0]["email"],
license=pyproject["project"]["license"],
license="Apache-2.0",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory this is deprecated, but so is retworkx so I think it will be fine

@coveralls
Copy link

coveralls commented Aug 13, 2025

Pull Request Test Coverage Report for Build 17584542303

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 94.645%

Totals Coverage Status
Change from base Build 16926345566: 0.0%
Covered Lines: 17815
Relevant Lines: 18823

💛 - Coveralls

Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably should move the sdist creation to using python -m build --sdist for rustworkx.
When I test this locally it's able to build the sdist without errors like the CI job had.

The build isolation from build probably won't work for retworkx because that's a bit more special but that's ok.

Comment on lines +5 to +6
branches:
- 'stable/0.17'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should undo this change, we don't want to forget about this. After this PR merges we can trigger the wheel build with a throwaway branch that we do as a one shot branched off of stable/0.17's HEAD. We'll also need to relax the release protection to enable triggering from a branch but we can do that in a one off.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added an if condition to check that the date is today, does that work?

@IvanIsCoding
Copy link
Collaborator Author

@mtreinish I updated rustworkx's command to be python -m build --sdist.

For the one-off branch: I don't want to create yet another branch. Maybe we can reuse stable/0.17? I just added a check for today's date. That way we cannot trigger it by accident on the future.

@IvanIsCoding
Copy link
Collaborator Author

@mtreinish I tested that the content of this PR is uploadable: rustworkz. I had to change x -> z because we already had a test upload of 0.14.1.

https://test.pypi.org/project/retworkx/0.17.1/ also worked.

I think we can merge this just to unblock users that opt for pip install --no-binary. I will update the date in the GitHub workflow such that it only runs on September 8, 2025 (this Monday).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants