Improve `CliConfig` / `CliClient` constructor naming and discoverability

[Keinberger]

Context

From PR #1642 discussion, questions were raised about the naming and structure of CliConfig and CliClient constructors.

Current API

• CliConfig::default() - creates a config with default relative paths
• CliConfig::from_system() - loads config from local/global .miden directories (recommended)
• CliClient::from_system_user_config() - creates a client using CLI config discovery (recommended)

Feedback

1. The naming from_system() and from_system_user_config() doesn't clearly convey these are the recommended constructors
2. The role of CliConfig::default() vs from_system() may be confusing to users

Current constraints

• Default::default() is used by the figment Provider trait impl (config.rs:71) and the init command (init.rs:167)
• Using default() for filesystem I/O would be non-idiomatic in Rust

Potential approaches

• Rename to more intuitive names (e.g., CliClient::new(), CliConfig::load())
• Keep current naming but improve documentation
• Restructure to make the recommended path more obvious

References

• PR feat: implement CliClient  #1642
• This comment by @mmagician : feat: implement CliClient  #1642 (comment)
• This comment by @mmagician : feat: implement CliClient  #1642 (comment)

[Farukest]

Hi @Keinberger
I'd like to work on this. Which approach do you prefer?

1. Rename (load(), new())
2. Documentation only
3. Both

Also, should this be a breaking change or add new methods as aliases?

[Keinberger]

Hey @Farukest, sorry for the delayed response!

I think option 3 (both rename + documentation) would be the most complete approach. The current naming (load, new) isn't very discoverable, so renaming to clearer method names would help. Since @bobbinth mentioned he's fine with breaking backwards compatibility at this stage (in #1697), I'd say a breaking change is acceptable here, no need for aliases.

That said, a lot of this was already addressed in the documentation improvements I made as part of the recent refactor. Let me take another look at the current state and I'll follow up with more specific guidance on what's still needed.

Thanks!

[Farukest]

Thanks @Keinberger! I've already implemented the rename + documentation approach in my branch:

• CliConfig::from_system() → CliConfig::load()
• CliClient::from_system_user_config() → CliClient::new()

All doc comments updated to reflect the new names. Breaking change, no aliases. PR is up whenever you're ready to review.

[Keinberger]

Replied on the PR!