-
Notifications
You must be signed in to change notification settings - Fork 173
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
Crate restructuring #590
Crate restructuring #590
Conversation
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.
👍
@maciejhirsz The PR description is a bit lacking here. Can you elaborate on why removing the |
@dvdplm Should be all tidy now + rationale, thoughts on having a linter for forcing braces on all the imports? Edit: also @niklasad1 opinions here? :) |
..., I thought we used
I don't like the braces for single imports if that's what you are suggesting but.... feel free to convince me :) |
We did? I thought it was just to keep stuff separate and it always bugged me. Given that 2.0 is the only version we support, and I don't think it's likely to change in the future I also don't see why we would need that differentiation.
Or
(these names are short enough to fit in a single line, but you get the idea) |
I think it was removed in https://github.com/paritytech/jsonrpsee/pull/269/files, maybe it's not needed but made it clear for which part of
I don't care that much about that but I like 👇 better
|
Yeah, that's my preference too, I can revert some of the imports here. |
It was never so much about versioning as it was about separating spec mandated types from the rest. The types from the spec must be kept intact forever while other public types can change with a breaking release. I think that is a worthy motivation for keeping things separate, and |
I don't think that's true, we can easily make a breaking change to a spec type by changing stuff like |
You are correct, but you're missing the point: these types do require some extra care outside of the normal semver compatibility narrative. Question is: is this something that is worth signalling by keeping them in their own namespace? I think so, and that's what lies behind the |
After discussion here's the plan:
|
@@ -590,7 +593,7 @@ async fn background_task( | |||
} | |||
} | |||
// Error response |
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.
Clippy is angry about line 195
Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
} | ||
|
||
pub use beef::Cow; | ||
pub use serde::{de::DeserializeOwned, Serialize}; |
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.
maybe we should re-export Deserialize
here too..
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.
Mayhaps, we are also super inconsistent about reexports, sometimes we put them in __reexports
module, and sometimes not, I'd leave that for a future PR.
hyper = { version = "0.14.10", default-features = false, features = ["stream"], optional = true } | ||
jsonrpsee-types = { path = "../types", version = "0.6.0", optional = true } | ||
hyper = { version = "0.14.10", default-features = false, features = ["stream"] } | ||
jsonrpsee-types = { path = "../types", version = "0.6.0" } |
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.
this crate is now what the v2
was?
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.
Correct
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.
LGTM, a few small questions....
This makes the repo structure more clear all good.
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.
lgtm, It generally looks way cleaner to me (ie. the imports are way easier to follow).
The Macro export for rpc_params
in core/src/client.rs
took me a hot second to understand because github formatted it very weird, but overall 👍 from me.
I need to start making smaller PRs. This one is pretty straight forward, removed the v2 module and moved things around to hopefully sensible locations.
Rationale: We added the
v2
module when doing some internal refactoring that ultimately lead to different versions of types with similar names (Request
most notably), but have since unified the apis to use same types, and with the "v1" absent there is no need for the module to exist.Edit: see comment for ongoing changes.