Add login / logout commands to `iggy` cli to reduce credentials related args / flags

[BartoszCiesla]

Introduce similar solution to docker login / docker logout - which would allow user to use iggy command line tool without a need of putting credentials for each command. (See https://docs.docker.com/engine/reference/commandline/login/ and https://docs.docker.com/engine/reference/commandline/logout/)

[melbourne2991]

Here's my thinking (happy to contribute to the below - have already started a rough draft).

It's similar to docker's login/logout concept, but closer to docker's concept of "contexts".

Keen to get your thoughts.

"Contexts"

This pattern is used in many products to minimize having to repeat arguments when interacting with a CLI, for instance:

• https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
• https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/
• https://docs.docker.com/engine/context/working-with-contexts/
• https://github.com/nats-io/natscli?tab=readme-ov-file#configuration-contexts

At a high level, you have a configuration file in a known location that maps a specific “context” or “profile” identifier to a piece of configuration. This configuration is then used implicitly in CLI interactions.

CLIs will often provide additional commands for managing contexts themselves. At a minimum there will typically be a command for “setting” the active context, to allow users to switch easily between them. 

Proposed implementation

• IGGY_HOME as an environment variable which if unset defaults to $HOME/.iggy
• The location of the contexts file defaults to $IGGY_HOME/contexts.toml
• The contents of the contexts file is a simple context name to configuration mapping
• We also require some state to be persisted representing the “active” context. The active context can be stored in  $IGGY_HOME/.active_context.
• When CLI commands are issued, the context’s configuration may be overridden with provided arguments.
  • Priority: CLI args, env vars, active context config

Context config

Key value pairs (context name -> config) in TOML. The config schema should (approximately) combine sdk/src/args.rs with username, password, token, token_name - with all fields optional. Absence of any field should behave as the CLI does today.

Two contexts:

# ~/.iggy/contexts.toml

[dev]
transport = "http"
username = "iggy"
password = "iggy" # Maybe not encouraged but permitted.
http_api_url = "http://localhost:3000"

[production]
transport = "tcp"
token_name = "token_ref"
tcp_server_address = "127.0.0.1:8090"
tcp_tls_enabled = "true"

To be set with:

iggy context set dev

iggy context set production

Additional considerations

How should the cli behave when contexts.toml / .active_context is undefined?

Possibly:

• The absence of contexts.toml results in the current CLI behavior
• The absence of .active_context when contexts.toml is present results in the “default” context being used, if specified within contexts.toml

Should there be an "unset" command?

Initial implementation

As a first cut I would suggest:

• Allow for setting the active context
• Require manual creation/editing of contexts.toml

Nice to have(s)

• Allow creation/deletion of new contexts via the CLI

[T1B0]

@melbourne299 aws cli use '--profile' explicitely on command, only the "default" is persisting. i think "profile" are an override applied over default (e.g. if your profile does not override say 'region', default region will be used). I don't see how context persistence would work with different cli instances running in parallel from the same user, seems tricky/footgun-ish too imo.

[melbourne2991]

@melbourne299 aws cli use '--profile' explicitely on command, only the "default" is persisting. i think "profile" are an override applied over default (e.g. if your profile does not override say 'region', default region will be used).

Yes, AWS's implementation is a little different. The NATS and Docker examples are closer aligned to what is proposed.

I don't see how context persistence would work with different cli instances running in parallel from the same user, seems tricky/footgun-ish too imo.

Taking docker & nats as an example, both have a global --context flag, so you can override the context for a specific interaction.

[BartoszCiesla]

@melbourne2991 do you want to continue with store / save commands as discussed in #612 ?