Skip to content
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

Merged
merged 28 commits into from
Dec 17, 2021
Merged

Crate restructuring #590

merged 28 commits into from
Dec 17, 2021

Conversation

maciejhirsz
Copy link
Contributor

@maciejhirsz maciejhirsz commented Dec 6, 2021

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.

@maciejhirsz maciejhirsz requested a review from a team as a code owner December 6, 2021 08:38
types/src/lib.rs Outdated Show resolved Hide resolved
Copy link
Member

@niklasad1 niklasad1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@dvdplm
Copy link
Contributor

dvdplm commented Dec 6, 2021

@maciejhirsz The PR description is a bit lacking here. Can you elaborate on why removing the v2 module is good? Not saying I disagree, but it is there for a reason (separate spec-mandated types from the rest) so it'd be good to write down why that reason is invalid/superseded.

utils/src/server/helpers.rs Outdated Show resolved Hide resolved
@maciejhirsz
Copy link
Contributor Author

maciejhirsz commented Dec 9, 2021

@dvdplm Should be all tidy now + rationale, thoughts on having a linter for forcing braces on all the imports?

Edit: also @niklasad1 opinions here? :)

@niklasad1
Copy link
Member

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.

..., I thought we used v2 to indicate that these types are JSON-RPC v2 spec related types and not just common types after we removed the JSON-RPC spec related from the jsonrpc crate (way back). I like this change because it's a bit annoying to have to write jsonrpsee_types::v2::Response instead of jsonrpsee_types::Response...

thoughts on having a linter for forcing braces on all the imports

I don't like the braces for single imports if that's what you are suggesting but.... feel free to convince me :)
Then we need some special rustfmt rule...

@maciejhirsz
Copy link
Contributor Author

..., I thought we used v2 to indicate that these types are JSON-RPC v2 spec related types (...)

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.

I don't like the braces for single imports if that's what you are suggesting but.... feel free to convince me :)
Then we need some special rustfmt rule...

use foo::{a, b, c};
use foo::{d, e, f};

Or

use foo::{
    a, b, c,
    d, e, f,
};

(these names are short enough to fit in a single line, but you get the idea)

@niklasad1
Copy link
Member

niklasad1 commented Dec 9, 2021

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.

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 types that were just shared/common types in the repo and v2 - types that were strictly JSON-RPC specification related. However, I like it :)

(these names are short enough to fit in a single line, but you get the idea)

I don't care that much about that but I like 👇 better

use foo::{a, b, c};
use foo::{d, e, f};

@maciejhirsz
Copy link
Contributor Author

I don't care that much about that but I like point_down better

Yeah, that's my preference too, I can revert some of the imports here.

@dvdplm
Copy link
Contributor

dvdplm commented Dec 10, 2021

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.

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 v2 seemed like a decent enough name for it.
However, given that wasn't clear to you @maciejhirsz I bet it isn't to many others, so we should perhaps consider a different name, maybe types::spec::StuffFromTheSpec?

@maciejhirsz
Copy link
Contributor Author

The types from the spec must be kept intact forever while other public types can change with a breaking release.

I don't think that's true, we can easily make a breaking change to a spec type by changing stuff like String to Cow<'a, str>, or getting rid of the TwoPointZero type and just building a manual Serialize impl on request etc., without breaking spec compatibility.

@dvdplm
Copy link
Contributor

dvdplm commented Dec 12, 2021

I don't think that's true, we can easily make a breaking change to a spec type by changing stuff like String to Cow<'a, str>, or getting rid of the TwoPointZero type and just building a manual Serialize impl on request etc., without breaking spec compatibility.

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 v2 module.
I'm not opposed to rename the module and I'm willing to listen to arguments against keeping them separate from the rest but so far I remain unconvinced.

@dvdplm
Copy link
Contributor

dvdplm commented Dec 14, 2021

After discussion here's the plan:

  1. Rename jsonrpsee_utils to jsonrpsee_core
  2. Rename jsonrpsee_types::RpcError to jsonrpsee_types::ErrorResponse.
  3. Move everything that's not a JSON-RCP transport type from jsonrpsee_types to jsonrpsee_core. This includes:
    3.1 Middleware and traits.
    3.2 Serialize, DeserializeOwned, beef::Cow, to_json_value, to_json_raw_value re-exports.
    3.3 All the error stuff that's not ErrorResponse, enums and other internal utils.

@maciejhirsz maciejhirsz changed the title Nuke types::v2 [WIP] Crate restructuring Dec 14, 2021
@@ -590,7 +593,7 @@ async fn background_task(
}
}
// Error response
Copy link
Contributor

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

@niklasad1 niklasad1 self-requested a review December 14, 2021 17:04
core/src/server/mod.rs Outdated Show resolved Hide resolved
core/src/server/mod.rs Outdated Show resolved Hide resolved
maciejhirsz and others added 2 commits December 16, 2021 15:26
Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
@maciejhirsz maciejhirsz changed the title [WIP] Crate restructuring Crate restructuring Dec 16, 2021
}

pub use beef::Cow;
pub use serde::{de::DeserializeOwned, Serialize};
Copy link
Member

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..

Copy link
Contributor Author

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.

core/src/traits.rs Outdated Show resolved Hide resolved
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" }
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

Copy link
Member

@niklasad1 niklasad1 left a 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.

@maciejhirsz maciejhirsz requested a review from a team December 17, 2021 08:45
Copy link
Member

@TarikGul TarikGul left a 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.

@maciejhirsz maciejhirsz merged commit e159c44 into master Dec 17, 2021
@maciejhirsz maciejhirsz deleted the mh-cleanup branch December 17, 2021 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants