Skip to content

Conversation

savente93
Copy link
Contributor

@savente93 savente93 commented Aug 8, 2025

Fixes #3

This PR makes quite a few changes but I like this approach:

  1. instead of relying on the tools itself, it just parses the project files, and does the version arithmetic itself.
  2. Stricter bounds and other specifiers are respected
  3. path and url_spec dependencies are also ignored.
  4. This action will open a PR ala dependabot, but for that it does require a token with the correct permissions (unavoidable I think)
  5. There are tests for most of the code, and I've tested it in a dummy repo (https://github.com/savente93/spec_0_test_package) which gives me more confidence in the robustness of this solution.
  6. I went for the 80/20 rule, so this solution works but isn't very feature rich, and takes some shortcuts in places. I think this is a good starting point where things can get added if necessary.
  7. I went with sensible defaults over configuration to keep the first version simple, but I'm open to making it more configurable if that's desirable.

@savente93 savente93 force-pushed the feat/python branch 23 times, most recently from 1a90157 to 68ed38d Compare August 11, 2025 12:25
@savente93 savente93 marked this pull request as ready for review August 11, 2025 12:36
The release_schedule workflow should create the artifacts on this
repository so other repositories can access it, and make sure we have a
paper trail
Action should create a PR with updated dependencies. Target branch and
tool to be used are configurable. Currently only pixi is supported but
it's good to make it possible to add other tools down the line
@savente93 savente93 force-pushed the feat/python branch 3 times, most recently from 1d00217 to 33c5e2f Compare August 15, 2025 08:42
@savente93
Copy link
Contributor Author

Right, I think it's ready for review now. Smoothed out a few kinks, and made it self testing, which I think is kinda nice. Looking forward to hearing your feedback!

@savente93
Copy link
Contributor Author

@nabobalis Would you be able to share when you might have time to review the PR? I’ve got a few people I’d like to start using this solution, and I’m hoping to keep up the momentum.

Copy link
Member

@nabobalis nabobalis left a comment

Choose a reason for hiding this comment

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

I have not had time to run the code locally, but I am happy to merge and get it going and see what bugs we hit in a live environment.

@nabobalis
Copy link
Member

@nabobalis Would you be able to share when you might have time to review the PR? I’ve got a few people I’d like to start using this solution, and I’m hoping to keep up the momentum.

Hi Sam, sorry about that. I went on vacation, so I just gave it a very quick once over and I am happy to merge and see how it works live.

Copy link
Member

@bsipocz bsipocz left a comment

Choose a reason for hiding this comment

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

There are a lot of review comments from both of us, so please don't merge it prematurely, I would rather get this right than fix in production.

schedule.json Outdated
Copy link
Member

Choose a reason for hiding this comment

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

Why is this committed to the repo?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because it has to be part of the release that the action will check against. We could generate the schedule from scratch every time, but then you lose a paper trail of what was actually in it, so I personally think this solution is better.

@savente93
Copy link
Contributor Author

Thanks both, I'll look at it tomorrow, so hopefully the comments will be addressed by the time you wake up again

savente93 and others added 2 commits August 20, 2025 08:45
Co-authored-by: Nabil Freij <[email protected]>

Apply suggestions from code review

Co-authored-by: Nabil Freij <[email protected]>

Apply suggestions from code review

Co-authored-by: Brigitta Sipőcz <[email protected]>
Copy link
Contributor Author

@savente93 savente93 left a comment

Choose a reason for hiding this comment

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

I've addressed all comments I could. There are a few questions still open but hopefully those will be cleared up easily


def update_dependency_table(dep_table: dict, new_versions: dict):
for pkg, pkg_data in dep_table.items():
# don't do anything for pkgs that aren't in our schedule
Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm, depends on what you're imagining. it could update things that aren't in the schedule potentially but we need to know what to update it too. I'm not entirely sure what you're asking here, if you have a change you want made could you elaborate?

schedule.json Outdated
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because it has to be part of the release that the action will check against. We could generate the schedule from scratch every time, but then you lose a paper trail of what was actually in it, so I personally think this solution is better.

@savente93 savente93 requested a review from bsipocz August 20, 2025 07:51
@savente93
Copy link
Contributor Author

@bsipocz I've addressed or responded to your comments. Could you take another look?

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.

Discussion ticket for action design
3 participants