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

refactor: create separate binary crates and move TrinConfig to trin crate #1614

Merged
merged 8 commits into from
Jan 7, 2025

Conversation

KolbyML
Copy link
Member

@KolbyML KolbyML commented Dec 26, 2024

What was wrong?

#1609 trin reporting versioning is broken. I need versioning working for ping extensions.

This is one PR, but I am going to make another PR fixing versioning.

One issue was that, TrinConfig shouldn't be in Ethportal-api and Trin's binary shouldn't be defined in the global cargo file

This causes a recursive import in ethportal-peertests.

Anyways I am making this PR for multiple reasons, I just haven't felt enough pain to clean things up until now

How was it fixed?

  • move src/bin/*'s into separate crates
  • move TrinConfig into Trin's binaries crate. It really shouldn't be in ethportal-api

@KolbyML KolbyML force-pushed the restructure-trin branch 2 times, most recently from 540182a to bcbee34 Compare December 27, 2024 09:28
@KolbyML KolbyML marked this pull request as ready for review December 27, 2024 09:31
@KolbyML KolbyML force-pushed the restructure-trin branch 3 times, most recently from e16cdf9 to 3dbc59a Compare December 27, 2024 11:58
Copy link
Member

@ogenev ogenev left a comment

Choose a reason for hiding this comment

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

Having the trin cli config in ethportal-api is something that bugged me for a long time, great!

tokio.workspace = true
tracing.workspace = true
trin-utils.workspace = true
url.workspace = true
Copy link
Member

Choose a reason for hiding this comment

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

nit: No new line at the end of file.

portalnet.workspace = true
tracing.workspace = true
trin-storage.workspace = true
trin-utils.workspace = true
Copy link
Member

Choose a reason for hiding this comment

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

nit: No new line at the end of file

@@ -2,7 +2,6 @@
name = "ethportal-api"
version = "0.4.0"
description = "Definitions for various Ethereum Portal Network JSONRPC APIs"
build = "build.rs"
Copy link
Member

Choose a reason for hiding this comment

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

Why the removal of this? In vergen docs it is required: https://docs.rs/vergen/latest/vergen/#usage

Copy link
Member Author

Choose a reason for hiding this comment

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

I think we should discuss this in this PR #1615

I did some testing and if you are building it doesn't seem required. I also checked other projects which used vergen such as Reth and they removed build = "build.rs" as well.

build = "build.rs" isn't friendly with publishing crates to crates.io and it doesn't seem needed for our usecase.

Copy link
Member

Choose a reason for hiding this comment

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

Fair enough 👍 .

Copy link
Member

Choose a reason for hiding this comment

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

Why are we leaving this file in ethportal-api and we are not moving all helper methods to trin/src/cli.rs ?

Copy link
Member Author

Choose a reason for hiding this comment

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

portal-bridge is using these helper functions too, maybe we can move them to trin-utils instead? What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, yeah, if more than one crate uses them, trin-utils seems a reasonable candidate.

use r2d2::Pool;
use r2d2_sqlite::SqliteConnectionManager;

use crate::{error::ContentStoreError, utils::setup_sql, DistanceFunction};

const BYTES_IN_MB_U64: u64 = 1000 * 1000;

/// The storage capacity configurtion.
#[derive(Debug, Clone, PartialEq, Eq)]
Copy link
Member

Choose a reason for hiding this comment

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

What is the reason for this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

It can't be stored in the trin binary crate as trin-storage depends on it and I can't think of a reason it should be in ethportal-api

}

impl TrinConfig {
pub fn portalnet_config(&self, private_key: B256) -> PortalnetConfig {
Copy link
Member

Choose a reason for hiding this comment

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

Not sure if I like this pattern, I prefer implementing the From trait for PortalnetConfig and RpcConfig.

impl From<TrinConfig> for PortalnetConfig {
...
}

impl From<TrinConfig> for RpcConfig {
...
}

Copy link
Member Author

Choose a reason for hiding this comment

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

I can do From for RpcConfig, but I can't for impl From<TrinConfig> for PortalnetConfig { as it requires the private_key: B256 argument

Copy link
Member

Choose a reason for hiding this comment

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

OK, we can then change the function name to to_portalnet_config because we are not consuming self and will follow the naming conventions.

use alloy::transports::http::reqwest::Url;
use ethportal_api::types::{cli::Web3TransportType, network::Subnetwork};

pub struct RpcConfig {
Copy link
Member

Choose a reason for hiding this comment

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

nit: a docstring is always nice

@KolbyML
Copy link
Member Author

KolbyML commented Jan 6, 2025

@ogenev ready for another review, I want to review this PR first #1615

Copy link
Member

@ogenev ogenev left a comment

Choose a reason for hiding this comment

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

Left a comment for moving the helper functions to trin-utils.

Anyways, the PR looks good 👍 .

Cargo.toml Outdated
[workspace]
members = [
"bin/historical-batch",
"bin/poll-latest",
"bin/purge-invalid-history-content",
Copy link
Collaborator

@njgheorghita njgheorghita Jan 7, 2025

Choose a reason for hiding this comment

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

hmmm. now it seems like the overhead for including these single-task binaries is higher than before. given that we don't really use these in production, I'd be in favor of removing all of them, except for one, to leave a framework for how to do it in future scenarios. Though, this can be done in a follow-up pr np

Copy link
Member Author

Choose a reason for hiding this comment

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

ok which one do you want to keep

Copy link
Member Author

Choose a reason for hiding this comment

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

For tooling we could make x,y,z subcommands in the trin cli, which would make there versions be tied. I think the purge script makes sense as a Trin sub command specifically

Copy link
Collaborator

Choose a reason for hiding this comment

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

Idk... honestly does it make sense to keep any of them around? None of them are used / have been in use recently afaik. And maybe we should migrate these kinds of tasks to the "subcommand" pattern, which might enforce a bit more of a thorough design/plan rather than these single-use scripts, which are a bit hacky....

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok I will remove them all then, as I don't have any specific attachment to them either

use crate::{
types::{bootnodes::Bootnodes, network::Subnetwork},
version::FULL_VERSION,
use ethportal_api::{
Copy link
Collaborator

Choose a reason for hiding this comment

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

I feel like this refactor should have removed some dependencies from ethportal-api? At least clap ... maybe url?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good call!

Cargo.toml Outdated
[workspace]
members = [
"bin/historical-batch",
"bin/poll-latest",
"bin/purge-invalid-history-content",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Idk... honestly does it make sense to keep any of them around? None of them are used / have been in use recently afaik. And maybe we should migrate these kinds of tasks to the "subcommand" pattern, which might enforce a bit more of a thorough design/plan rather than these single-use scripts, which are a bit hacky....

Copy link
Collaborator

@njgheorghita njgheorghita left a comment

Choose a reason for hiding this comment

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

You'll also need to remove the refs to the deleted scripts in the dockerfiles

@KolbyML
Copy link
Member Author

KolbyML commented Jan 7, 2025

You'll also need to remove the refs to the deleted scripts in the dockerfiles

good catch

@KolbyML KolbyML merged commit c5de5a5 into ethereum:master Jan 7, 2025
9 checks passed
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.

3 participants