Split into library and binary #149
Conversation
metamath-rs/Cargo.toml
Outdated
| name = "metamath-rs" | ||
| readme = "metamath-rs/README.md" | ||
| description = "A library manipulating Metamath databases, including a parallel and incremental verifier for Metamath databases" | ||
| version.workspace = true |
There was a problem hiding this comment.
I think the two crates should be versioned separately.
There was a problem hiding this comment.
To me the advantages of a single version system is:
- anyway both will always be kept in sync because they are in the same repo,
- there will be a single release tags used to generate versions in crates.io
- less versions to keep track of / update
Which would be the pros of different versions / in which cases do you see them diverging?
There was a problem hiding this comment.
I think it would be unfortunate if we have to release new library crate versions for changes to the CLI, or vice versa. AFAIK there isn't any special relation between git tags and crates.io releases unless we want there to be.
I think we can have versions on related tracks, but I would expect them to differ in their patch versions most of the time. They are two separate crates in a dependency relationship, and dependencies are generally versioned entirely separately, even if they are in the same repo. The only thing that same-repo implies is that the dependent crate (here the CLI) will be using the version of the library from HEAD (as a path dependency), or possibly the public version of that right after a release. Making the versions exactly match seems like it would just make a mess of semver because that's not what it was designed for.
There was a problem hiding this comment.
I see, thanks: I've made the change.
I was unsure which version to use, so I simply put the current 0.3.6 for both. They can diverge in the future.
There was a problem hiding this comment.
Despite the thumbs up, I'm unsure if I should go ahead and merge this, with massive changes in #116 pending.
There was a problem hiding this comment.
Either way there will be a merge. Maybe 116-first is easier? But you probably have better intuition than anyone on that point.
There was a problem hiding this comment.
I think it would be better to proceed with this first, as it is comparatively simpler and doesn't involve any deep technical questions. It doesn't seem like there are any dissenting voices to this PR, so I'll merge it now and we can update the existing PRs to match.
Along the lines of #117, this splits the repository into 2 crates, one library crate
metamath-rsand one binary cratemetamath-knife.This is a naive split with as few functional changes as possible, moving files around with
git mv, unchanged.Fixes #117.