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 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
@nabobalis
Copy link
Member

Would you want me to review 4 first and get that merged in then rebase this PR or did you have something else in mind?

@savente93
Copy link
Contributor Author

savente93 commented Aug 14, 2025

Yeah, that's about what I figured would be the easiest for the reviewer, 4 is more about the structure of how the action will function, and this one is more about how the version logic works.

EDIT: though if you think it's less work to just review this in one go, that's totally fine with me too, since there are a few changes in 4 that are superseded by this one. Whatever you prefer is okay with me

@savente93
Copy link
Contributor Author

Also I just noticed the rename, because my personal fork is still named under the old name, I'll leave it just now, but I'll align it all before merging if this is the approach that people like

@nabobalis
Copy link
Member

Ah yeah, I forgot about that! I think github will keep the old name alive for a while, so we shouldn't need to be in any rush.

@nabobalis
Copy link
Member

To be honest, I think just reviewing one PR would be easier for me even if its larger.

@savente93
Copy link
Contributor Author

Okay that's totally fine, then I'll just close the other one :) This one is mostly review ready, I just need to clean up a few small things but the logic is all there. I'll probably fix that tomorrow

@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.

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

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?

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?

@savente93
Copy link
Contributor Author

@bsipocz Would you be able to give an estimate of when you'll be able to have another look at this?

@savente93
Copy link
Contributor Author

never mind I suppose

@savente93 savente93 closed this Sep 29, 2025
@nabobalis
Copy link
Member

Hi @savente93, sorry for the lack of responses. Things are kind chaotic in the US side due to various events.

Could you please reopen this? I want to still try and get this merged this side of the Thanksgiving.

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