chore: support specify contract path input with or without -p flag

[ndkazu]

Description

This PR is addressing issue #350.
Allow pop-cli to supports two ways to to specify the path to a contract or artifact file: using the -p flag or specifying the path directly without it:

pop call contract -p ../contract.json 

and

pop call contract ../contract.json

should both be possible.

Implementation

Two arguments are used to specify the path: One Optional, and one positional:

#[arg(long,required = false)]
	pub(crate) path: Option<PathBuf>,
	#[arg(value_name = "PATH",required = false)]
	pub(crate) path1: Option<PathBuf>,

The following contract-related commands will be upgraded

• pop build
• pop up contract
• pop call contract

[AlexD10S]

Thanks for your interest in contributing to pop-cli!
I’ve reviewed your approach, and maintaining a second argument path1 might not be the cleanest way to solve this.
You might want to explore using positional arguments, as discussed here clap-rs/clap#2260, or consider the use of subcommands (https://docs.rs/clap/latest/clap/trait.Subcommand.html) instead.

[ndkazu]

Thanks for your interest in contributing to pop-cli! I’ve reviewed your approach, and maintaining a second argument path1 might not be the cleanest way to solve this. You might want to explore using positional arguments, as discussed here clap-rs/clap#2260, or consider the use of subcommands (https://docs.rs/clap/latest/clap/trait.Subcommand.html) instead.

Hello, I looked into it, and it seems to me that what we're trying to do is closer to this, and this.
and from what I understood from these discussions involving the Clap devTeam, it seems like using two arguments is the way to go(maybe not the way I did it though... maybe use required_unless = ... instead of required = ... ). An experimental module exists here, but I don't think the CLAP team is wiling to consider it.

[ndkazu]

@AlexD10S , I made a cleaner version of my first suggestion (modifications are minimal, and limited to pop build ...). I am still looking for other (less invasive?) routes, but based on my previous comment, let me know if it makes sense to propagate this method to pop up contract & pop call contract.

[AlexD10S]

@AlexD10S , I made a cleaner version of my first suggestion (modifications are minimal, and limited to pop build ...). I am still looking for other (less invasive?) routes, but based on my previous comment, let me know if it makes sense to propagate this method to pop up contract & pop call contract.

Thanks! Running the CI to check all tests pass, and I'll do a proper review

[ndkazu]

@AlexD10S , I made a cleaner version of my first suggestion (modifications are minimal, and limited to pop build ...). I am still looking for other (less invasive?) routes, but based on my previous comment, let me know if it makes sense to propagate this method to pop up contract & pop call contract.

Thanks! Running the CI to check all tests pass, and I'll do a proper review

I saw that the CLI was failing, and did a cargo +nightly fmt as a tentative to fix the error.

[codecov]

Codecov Report

Attention: Patch coverage is 68.33333% with 19 lines in your changes missing coverage. Please review.

Project coverage is 75.11%. Comparing base (cbf722a) to head (b4af4fd).

Files with missing lines	Patch %	Lines
crates/pop-cli/src/commands/up/contract.rs	42.85%	7 Missing and 1 partial ⚠️
crates/pop-cli/src/commands/build/mod.rs	12.50%	7 Missing ⚠️
crates/pop-cli/src/commands/call/contract.rs	87.50%	3 Missing and 1 partial ⚠️

@@            Coverage Diff             @@
##             main     #361      +/-   ##
==========================================
- Coverage   75.15%   75.11%   -0.05%     
==========================================
  Files          62       62              
  Lines       13820    13849      +29     
  Branches    13820    13849      +29     
==========================================
+ Hits        10386    10402      +16     
- Misses       2082     2097      +15     
+ Partials     1352     1350       -2     

Files with missing lines	Coverage Δ
crates/pop-cli/src/common/contracts.rs	60.90% <100.00%> (+1.84%)	⬆️
crates/pop-cli/src/commands/call/contract.rs	80.30% <87.50%> (-0.34%)	⬇️
crates/pop-cli/src/commands/build/mod.rs	49.39% <12.50%> (-1.24%)	⬇️
crates/pop-cli/src/commands/up/contract.rs	34.07% <42.85%> (+0.15%)	⬆️

... and 1 file with indirect coverage changes

[ndkazu]

Any update? should I propagate the modification to pop up contract & pop call contract ?

[evilrobot-01]

Any update? should I propagate the modification to pop up contract & pop call contract ?

Sorry for the delay, we have been readying a release. @AlexD10S could you provide some feedback on next steps here please?

[AlexD10S]

Thank you for sharing these resources! They were very helpful in understanding the best approach. While I'm not thrilled about it, it seems that keeping the two arguments is the most practical solution, great job.

A couple of quick changes:

If you run pop in your parachain or contract folder, there’s no need to specify the path. That's why we changed the argument to Option.
You could remove required_unless_present and probably makes sense to use index = 1.

It might also be helpful to add conflicts_with = "path" so that users don’t accidentally specify both positional and named paths, like this:

pop build ../my_contract --path ../my_contract_2

Here's an example of how the argument definition could look:

/// Directory path without flag for your project [default: current directory]
#[arg(value_name = "PATH", index = 1, conflicts_with = "path")]
pub(crate) path_pos: Option<PathBuf>,

Finally, with this optional path in mind, the code where you determine project_path can be simplified to something like this:

 let project_path = if let Some(path_pos) = args.path_pos {
        Some(path_pos) // Use positional path if present
    } else {
        args.path // Otherwise, use the named path
    };

Great work so far, and thank you for your patience while I got around to reviewing this! Apologies for the delay.

[AlexD10S]

Good work!
I left some comment mainly to refactor repetitive code.
The important thing to fix are the unit tests that are failing. I think it can be because you specify both path and path_pos in the tests and then the result is not the expected.
Review the tests and adjust it. I'd probably leave path and path_pos to None in most of the tests except one where use path_pos or have a specific one to test the path_pos functionality

You can test them locally with: cargo test --lib --bins.

[AlexD10S]

Thanks for the fixes! I noticed the CI is failing because the get_project_path function, used for both contracts and parachain, was moved to a file that only works under the contracts feature, see: https://github.com/r0gue-io/pop-cli/blob/main/crates/pop-cli/src/common/mod.rs#L3

you can test it with: cargo check --no-default-features --features parachain

You can fix this by either removing the line above or, better yet, moving the function to a shared file under common (maybe a new build.rs).
Also, please add comments to the method.

[ndkazu]

@AlexD10S , I see that all CI checks are passing: what's next?

[evilrobot-01]

Alex is OOO today, so expect a response when he is back tomorrow.

[AlexD10S]

Great job! Everything looks excellent. Thank you for your patience and effort in addressing all the requested changes.