Conversation
|
Do you want me to review and merge now or when all sub0 TODO tasks are completed? We should create a separate issue to track M1 and M2 tasks Also suggest a change for the name of the PR to follow this conventions https://www.conventionalcommits.org/es/v1.0.0-beta.2/ A suggestion will be feat: pop add pallet |
|
@AlexD10S This should be ready for merging when a few more tasks out of sub0 is completed. |
| // NodePalletDependency(dep) => te.inject_node(dep)?, | ||
| // ListBenchmarks(step) => pe.insert(step), | ||
| // ListBenchmarks(step) => pe.insert(step), | ||
| // ChainspecGenesisConfig(step) => pe.insert(step), | ||
| // ChainspecGenesisImport(step) => pe.insert(step), |
There was a problem hiding this comment.
Their implementation is required later.
|
First thing I notice is that the pallet generated from |
Correct. The feature is not implemented yet but is up for discussion here : #71 |
Daanvdplas
left a comment
There was a problem hiding this comment.
- We could potentially add the pallet to the runtime/src/lib.rs commented, then the user has to fill it in the Config items themselves. This would allow to take any pallet config and copy paste it in the runtime. The
DefaultConfigtransition is something that can be very beneficial to this feature: paritytech/polkadot-sdk#3637
example: https://github.com/paritytech/polkadot-sdk/pull/3637/files
With this, the user would only have to implement the left over Config items not handled by the DefaultConfig.
-
let the user specify the pallet index to use in the runtime:
pop add pallet frameorpop add pallet --path <path to runtime> -
You very specifically explain what is happening in the code, very nice. However, it would also be nice if you could explain it in a more human understandable way.
| steps.push(RuntimePalletImport(( | ||
| quote!( | ||
| // Imports by pop-cli | ||
| pub use pallet_parachain_template; |
There was a problem hiding this comment.
The template that is created has a name. Could we name the pallet like that?
pop new pallet test will result here into pallet_test
There was a problem hiding this comment.
So, what you're looking at here is code for adding the default pallet-parachain-template that lives on cumulus (and subsequently, on the pallet template used by pop new pallet template). There is no support yet to handle custom pallets created by pop new or FRAME.
There was a problem hiding this comment.
Yet but is it not meant for adding a pallet that the user created? Don't see much reason for adding the pallet template. Someone creates a new pallet pop new pallet awesome_pallet and then someone wants to add that pallet to the runtime pop add pallet --path pallets/awesome_pallet
There was a problem hiding this comment.
Reading also the other comments I made regarding this topic. What is there for value in adding the pallet_parachain_template? The user will then have to change the name themselves everywhere
| steps.push(SwitchTo(State::Config)); | ||
| steps.push(RuntimePalletConfiguration(( | ||
| quote!( | ||
| /// Configure the pallet template in pallets/template. |
There was a problem hiding this comment.
"Configure pallet test in pallets/test."
Same for all the other places where this will have an effect.
There was a problem hiding this comment.
See comment above please.
| steps.push(RuntimePalletConfiguration(( | ||
| quote!( | ||
| /// Configure the pallet template in pallets/template. | ||
| impl pallet_parachain_template::Config for Runtime { |
There was a problem hiding this comment.
TODO: this should be read from the pallet lib.rs
There was a problem hiding this comment.
See above please. Same reason as above.
| // Build Pallet Details | ||
| let __buf = BufReader::new(File::open(&input)?); | ||
| let file_end = __buf.lines().count(); | ||
| let rt = fs::read_to_string(&input)?; |
There was a problem hiding this comment.
Maybe this is me but I find this naming confusing, what does it stand for? Multiple cases in the code, any reason why besides shorter?
There was a problem hiding this comment.
Agree with Daan here, this part is not easy to follow. Clear naming or take some lines into specific function might help
| /// Add a new pallet to RuntimeDeclaration and return it. | ||
| /// Used to pass a typed AddPallet to modify the RuntimeDeclaration | ||
| /// Overwrites existing CRT in output, this means that `self.cursor` has to backtracked to crt_start | ||
| /// and updated after the pallet entry has been inserted |
There was a problem hiding this comment.
Sorry but I simply don't understand what you are saying here :)
You explain what is happening in the code very detailed, well done! However, it would make the reviewer's work, and anyone diving into the code, much more effective and easy if you could also add a high level explanation of what the code / function does. As a result, the reviewer can get a high level understanding of what the function is doing / meant to do before going going over the code in detail.
It would be really nice if you could document your code in a way where:
- First, you explain high level what this function does, or what the code from now on (when following the code) is about to do. in a way where a (parachain) developer understands what is about to happen and why.
- Second, provide additional detailed code explanation (this you already have).
There was a problem hiding this comment.
Yeah for this case, I should explain it better. So the commented code in add_pallet_runtime is altogether a different system that I had created during prototyping of pallet engine to add pallets to the CRT macro. What this does is effectively use the structure RuntimeDeclaration that's parsed from the source file, append to it with more checks such as indicies, instances, etc. (some of which have no implementation right now but are put off until we dive into handling duplicated entries), and update the tokens for the CRT macro in place in the output file.
This is a great idea. Would probably come to fruition when we start work on adding FRAME support.
This can be done as the machinery exists already, just not in the CLI. One thing to note here is that although unimplemented currently, when we start working on unique pallet additions or iow, a name conflict resolution strategy, pallet additions would automatically be indexed, respecting CRT checks such as the requirement for the index to be
I'll try my best. Thank you. |
About this discussion I don't have it very clear. pallet-parachain-template = { path = "/pathtoparachain/pallets/pallet-parachain-template", version = "1.0.0", default-features = false }Is that expected? For me is a bug, we should do automatically the |
As per https://crates.io/crates/tempdir, tempdir was deprecated ages ago with functionality moved into tempfile which already exists as a dependency. Primary motivation was a security advisory triggered by dependabot.
This is known, not expected at all and is a bug. Do you recommend we address #71 immediately @AlexD10S ? |
| /// Insert `pallet-parachain-template` into the runtime. | ||
| Template, | ||
| /// Insert a frame-pallet into the runtime. | ||
| Frame(FrameArgs), |
There was a problem hiding this comment.
I personally don’t like to have the FRAME logic there if is not working. It might be confusing for the user.
There was a problem hiding this comment.
Why would the user be confused when they're met with a not implemented message ? If I delete this scaffolding code which is minimal btw, I will have to rewrite it when we start with Frame which we are going to do anyways.
There was a problem hiding this comment.
With git there is no need to rewrite things, just take it from here into another branch.
There was a problem hiding this comment.
Sorry I have to disagree with that approach. Doesn't solve anything.
| } | ||
| path | ||
| }, | ||
| None => { |
There was a problem hiding this comment.
For UX, Is not better to use clap errors?. Will be add runtime_path as mandatory above
If i run cargo run add pallet template it panics
thread 'main' panicked at src/commands/add/mod.rs:62:17:
not implemented: provide a runtime path until feat:cache is implemented: --runtime <path>
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
If I run cargo run up parachain without the mandatory commands it shows me how to use the tool:
error: the following required arguments were not provided:
--file <FILE>
Usage: pop up parachain --file <FILE>
For more information, try '--help'.
There was a problem hiding this comment.
I agree. This makes more sense when we have a functional cache.. Just for the record,reason to use an Option here is to rely on automatic inference via the pop new cache in the case that user omits -r. But yeah seems right to make it required
| path | ||
| }, | ||
| None => { | ||
| // TODO: Fetch runtime either from cache |
There was a problem hiding this comment.
For TODOs is better to create an Issue, than lines of code
There was a problem hiding this comment.
Some of it is already in the issue and PR description. These are just placeholder comments from where future work can be easily picked up where these were left off.
|
|
||
| /// The main entry point into the engine. | ||
| pub fn execute(pallet: AddPallet, runtime_path: PathBuf) -> anyhow::Result<()> { | ||
| // Todo: Add option to source from cli |
| config: TemplatePalletConfig, | ||
| ) -> anyhow::Result<()> { | ||
| let target = resolve_pallet_path(path); | ||
| // TODO : config.name might use `-` or use snake_case. We want to use pallet_template for the pallet dirs |
There was a problem hiding this comment.
Don't think it's necessary anymore. Will remove.
| @@ -0,0 +1,913 @@ | |||
| #![allow(unused)] | |||
| // This file is part of Substrate modified to fit pallet manipulation needs for pop-cli | |||
There was a problem hiding this comment.
Do we use everything from here?
There was a problem hiding this comment.
Not yet. This is important when a future implementation will use in place editing of RuntimeDeclaration rather than inserting strings. It's basically the entire parser for construct_runtime!
| } | ||
| /// Create a new PalletEngine | ||
| pub fn new(input: &PathBuf) -> anyhow::Result<Self> { | ||
| let tmp_dir = PathBuf::from(format!("/tmp/pallet_engine_{}", uuid::Uuid::new_v4())); |
There was a problem hiding this comment.
Is not better to create and remove the /tmp/pallet_engine than having to add a uuid?
There was a problem hiding this comment.
How would you prevent name collisions?
There was a problem hiding this comment.
but the tmp folder is removed after no?
There was a problem hiding this comment.
No it's not. At least not in code. We are relying on linux system to clean it up by placing it under /tmp on reboot or on non-usage.
| frame-benchmarking = { version = "26.0.0", default-features = false, optional = true} | ||
| frame-support = { version = "26.0.0", default-features = false} | ||
| frame-system = { version = "26.0.0", default-features = false} | ||
| frame-benchmarking = { git = "https://github.com/paritytech/polkadot-sdk", branch = "release-polkadot-v1.7.1", default-features = false } |
There was a problem hiding this comment.
I added this line to make it work for Sub0, but is there another way?
Otherwise we will have to always update it here when updating base-parachain: https://github.com/r0gue-io/base-parachain/blob/main/Cargo.toml
There was a problem hiding this comment.
This entire template needs to be updated to use release-polkadot-* dependencies. Cannot have the base-parachain using them and this one using crates-io dependencies.
There was a problem hiding this comment.
On second thought, I think you've made the appropriate changes already.
Before merge to main yes |
Enable
pop-clito add pallets to any runtime.pop add pallet template -r <runtime_path>orpop a p template -r <runtime_path>sub0 Todos:
palletsubsubcommandM1 Todos:
add-palletneeds to check for duplicated entries. #63)pop new parachainto use as a runtime pathMilestone 2 :
Enable full FRAME pallet support
Nice to haves:
pop new parachainpop add pallet template