This change introduces a first-class profile management command to the Radicle CLI, enabling clean separation and safe switching of per-user configuration and keys by copying selected profile data into the root ~/.radicle/ directory (no symlinks).

Summary

• New command: rad profile
• Subcommands: new, switch, list, current, remove
• new: creates profiles/, activates it, and clears the root so rad auth can initialize cleanly
• switch: saves current root back to the active profile; then copies the target profile’s config.json and keys/* into ~/.radicle/
• Replace-in-place copy semantics to avoid partial states; cross-platform behavior

Documentation

• crates/radicle-cli/examples/rad-profile.md

Suggested labels: cli, feature, profiles

Looks very good in general! I’ve left some comments though. CI needs to be fixed. It is failing with Action failed: command failed: ["cargo", "fmt", "--check"].

Hey there, thanks a lot for your contribution!

That’s a very nice addition. I did a first review run on the initial revision and it looks good so far, but I’d need to spend some more time reviewing and testing it. Maybe we could already tackle the comments? Please feel free to also reach out on Zulip!

cli(profile): isolated profiles; copy-on-switch; explicit default

Introduce first-class profile management for the Radicle CLI.

Features

• Command: rad profile
• Subcommands: • new [–from ] [–force] • switch <name|default> [–print-env] • list | current | remove [-y]

Semantics

• Always show ‘default’ in listings; ‘current’ prints ‘default’ when no active profile is set.
• switch persists the current root back to the active profile, then copies the target profile’s config.json and keys/* into ~/.radicle/.
• switch default persists the current root (if any), clears ~/.radicle/ (config.json, keys/), and unsets the active profile marker; with –print-env it emits ‘unset RAD_PROFILE’.
• new clears the root so ‘rad auth’ can initialize cleanly.

Implementation

• No symlinks; replace-in-place copy to avoid partial states (portable).
• Robust RAD_HOME resolution (works before ‘rad auth’).
• Dedicated errors with thiserror; clippy/fmt clean.

Docs

• crates/radicle-cli/examples/rad-profile.md

okay, thank you for coming back. I’m making the changes you requested.

That’s a very nice addition.

How does this affect the node vs. user? I just skimmed this, and it appears that since it also copies the configuration, it also affects the configuration of the node.

I proposed a long time ago, see patch ed450c98018617 to make the key location used for radicle-node to be variable, and in that patch I add a configuration option to $RAD_HOME/config.json to set the key location for the node.

Do not get me wrong, I would love a command that changes the user identity like is proposed here, but I would like to be sure to understand how it fits into node vs. user.

Reading the description, I gotta admit that I get worried by all the copying of stuff. I would much rather have a simple profile file (~/.radicle.profile, perhaps?) that holds paths to the profile’s config.json and keys directory, and avoid all the copying.

My reason for worry is that any program can break, and if there’s a break while copying is going on, it will leave ~/.radicle in an inconsistent state. That’s a very big risk.

Yes, I understand your concern, and you are right. So far, it hasn’t caused any problems (I’ve been using it myself). Still, your concern is understandable. I plan to rewrite the code in a more professional way in the future.