-
Notifications
You must be signed in to change notification settings - Fork 59
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
Add Dockerhub publishing step to the release GitHub Action workflow #740
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
2b2cd9c
Add container image publishing step into release workflow
vsbogd c5dac54
Separate PyPi and DockerHub environment
vsbogd c5a69f3
Keep .git dir in order to correctly determine Python package version
vsbogd a9d9ff1
Fix version matching code in Rust REPL
vsbogd 6de40bc
Merge branch 'main' into automate-release
luketpeterson 61ee39b
Require Python package version to be equal to the REPL one
vsbogd e4d8f2b
Remove unused semver package
vsbogd File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 admit my hard-coded requirement was a bad solution and I am glad you are improving it.
I agree with what I think you're trying to do by using the repl's
package.version
; to reduce the number of configs we need to update and worry about when turning a release.However, I don't like this approach of creating a VersionReq for HyperonPy by assuming it'll be within 1 minor version of the repl version.
One thought is to use a requirement string created from the actual hyperonpy version in CMake. This makes releasing easy, but it becomes annoying to use cargo directly to build the repl.
Another thought is to use a custom metadata key in the Cargo.toml. It's still two keys to update but they're in one place.
For example:
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.
UPDATE: After trying to implement the custom Cargo.toml metadata solution, it seems like a clumsy solution. It appears to require parsing the Cargo.toml file ourselves. (At lease if the way docs.rs does it is the recommended way. https://github.com/rust-lang/docs.rs/blob/7ad8c626bd63a95dc483143274ff6f2410a34af9/crates/metadata/lib.rs#L103)
My thinking is that, if a "correct" solution is clumsy and probably not necessary, we should go with a "mostly-works" solution that is as simple as possible.
The purpose of the check is to prevent version incompatibilities from showing up as mysterious bugs that we waste time chasing. So if we plan to keep the components within a release in version lock-step, then I don't think we need the semver range.
So how about something like 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.
Yes, I agree that if we split repo on different components: corelib, python lib, repl, then we need to specify repl dependency manually. And keeping it in metadata looks like a proper way of doing this. I didn't think about it on the first place because Python package version right now is formed from the GitHub tag and its
major.minor.patch
version in a common case is equal to the version of the repl. In my suggestion I was trying to reproduce the previous code behavior using repl package version. Strictly speaking we cannot just rely repl and hyperonpy versions are changed by the same rules (because standards are different) but on the other hand while we are changing them we can rely on this.I agree that we can just require this versions to be equal while we have them in a same repo. This implementation should cover most of the cases. In practice dev Python package version always contains local version like
+ga9d9ff1a.d20240712
but as PEP440 requires local version to be compatible with non local one it passes check.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.
Applied your suggestion in 61ee39b