Add Dockerhub publishing step to the release GitHub Action workflow

[vsbogd]

Fix version checking procedure in REPL to not hardcode the required version (@luketpeterson please review).
Add Docker image building and publishing step into release workflow.
Separate test and production environments for PyPi and DockerHub to be able approve each step separately.

[luketpeterson]

The Python module versions aren't semver, they're pep440. It turns out there is enough overlap that it's possible to parse one as the other in the common cases, but I don't think it's right to rely on this coincidence.

[luketpeterson]

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:

[workspace.package.metadata.hyperonpy]
hyperonpy-version-req = "==0.2.0"

[luketpeterson]

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:

        fn required_hyperon_version() -> String {
            const PACKAGE_VERSION: &str = env!("CARGO_PKG_VERSION");
            format!("=={PACKAGE_VERSION}")
        }

[vsbogd]

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.

[vsbogd]

Applied your suggestion in 61ee39b

[luketpeterson]

I don't think we need the semver crate