Move public-api code to cargo-public-api repo
#95
Comments
Enselic
added a commit
to Enselic/cargo-public-api
that referenced
this issue
May 18, 2022
I am not adding an integration test for this fix, because I consider that blocked by Enselic/public-api#95. It is easy to manually verify this change though, just do this: cargo run -- --manifest-path ~/src/public-api/tests/crates/comprehensive_api/Cargo.toml | head -n 1 With the fix you get one line as expected. Without the fix you also get Error: Broken pipe (os error 32)
|
I agree, it feels more natural to me to have a monorepo. I would say that until both projects really get disconnected, separate teams working on it, being used by different end crates it is more logical to have them together. For the examples of having to update both crates I would say look at my contribution in colouring. There I needed to update the |
Enselic
changed the title
public-api code to cargo-public-api repopublic-api code to cargo-public-api repo
Enselic
added a commit
that referenced
this issue
May 22, 2022
In preparation of fixing #95. There will be no `tests` directory at the top-level any longer.
Enselic
added a commit
that referenced
this issue
May 22, 2022
In preparation of fixing #95, where `public-api` will also be part of a workspace.
Enselic
added a commit
to Enselic/cargo-public-api
that referenced
this issue
May 24, 2022
…-api/main' This adds the entire git history of the `main` branch of https://github.com/Enselic/public-api to this repo, and re-arranges the code to a workspace, and sneaks in some minor fixes for tests, docs, and Release.yml. No user bin or lib changes have been made. There is now two root commits in the git log. As far as I can tell the git tooling handles that well. See Enselic/public-api#95 for why we do this.
Enselic
added a commit
to Enselic/cargo-public-api
that referenced
this issue
May 24, 2022
…-api/main' This adds the entire git history of the `main` branch of https://github.com/Enselic/public-api to this repo, and re-arranges the code to a workspace, and sneaks in some minor fixes for tests, docs, and Release.yml. No user bin or lib changes have been made. There is now two root commits in the git log. As far as I can tell the git tooling handles that well. See Enselic/public-api#95 for why we do this.
This was referenced May 26, 2022
Enselic
added a commit
to Enselic/cargo-public-api
that referenced
this issue
May 26, 2022
…-api/main' This adds the entire git history of the `main` branch of https://github.com/Enselic/public-api to this repo, and re-arranges the code to a workspace, and sneaks in some minor fixes for tests, docs, and Release.yml. No user bin or lib changes have been made. There is now two root commits in the git log. As far as I can tell the git tooling handles that well. See Enselic/public-api#95 for why we do this.
|
This repo readme now points to the new place, and release via CI seems to work well from the new place. I consider this fixed now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have become more and more convinced that it would be beneficial to turn
public-apiandcargo-public-apiinto a mono-repo. Only on the repo level though. It still make a lot of sense forpublic-apiandcargo-public-apito remain two distinct crates.So all code would live in https://github.com/Enselic/cargo-public-api. And long-term possibly in https://github.com/cargo-public-api/cargo-public-api.
Pros
Easier development flow
There would only be a single project and git repo to manage in VS Code (or your IDE of choice).
And the default setup can be that
cargo-public-apiuses the local version ofpublic-api. Right now that is an extra step, which makes development slightly less convenient than it could be.Ability to re-use code for testing
The
public-apirepo has a very usefulcomprehensive_apitest crate, for example.cargo-public-apiwould get access to that crate too.Less duplicate efforts to make commits
There are many examples in the past where I essentially make the same commit to both projects, but separately. It would have been a lot more convenient to only have to make a single commit. TODO: Add examples
Easier to sync releases
Whenever we make a
public-apirelease, we practically always also want to make acargo-public-apirelease. Because we want to set thepublic-apidependency ofcargo-public-apito the latest version, to ensure that users gets the latest and greatest functionality.Having everything in the same repo makes it easier to sync releases.
It is however very possible that we in the future want to make only
cargo-public-apireleases, without bumpingpublic-api. But a mono-repo does not prevent us from doing that.Cons
I can't really think of any big cons. Losing some github stars, maybe? The project is still in the very early stages, so I think we can tolerate that :) Of course; the
public-apirepo will point towards thecargo-public-apirepo.Current status
This is still an idea. Before a final decision, we at the very least need a prototype commit to see how a mono-repo would look like. That is the next step for me.
@douweschulte Naturally, I would also love your feedback on this. (But as usual, there is no stress or urgency. I think this will be the last time I explicitly mention that :)
The text was updated successfully, but these errors were encountered: