Conversation
…ry-url>` in addition to the `--registry <registry-url>` long form
| #[clap(flatten)] | ||
| pub common: CommonOptions, | ||
|
|
||
| /// The URL of the registry to use. |
There was a problem hiding this comment.
Should we call out that this is an advanced option and plain registry is preferred?
There was a problem hiding this comment.
How do you mean "call out"?
I think either is OK. Just errors if you use both at the same time. Current look:
(base) > warg login -h
Manage auth tokens for interacting with a registry
Usage: warg login [OPTIONS] [URL]
Arguments:
[URL] The URL of the registry to use
Options:
--registry <URL> The URL of the registry to use
--config <CONFIG> The path to the client configuration file to use
--ignore-federation-hints Ignore federation hints
--auto-accept-federation-hints Auto accept federation hints
--keyring-backend <KEYRING_BACKEND> The backend to use for keyring access
-h, --help Print help (see more with '--help')
-V, --version Print version
There was a problem hiding this comment.
Maybe I'm just confused; what is the purpose of these two different arguments?
There was a problem hiding this comment.
I was trying to support both warg login --registry <registry-url> (to not break existing instructions but also migrate to warg login <registry-url>.
Been trying, but clap doesn't really support it best I can tell with the derive args
There was a problem hiding this comment.
Ah OK; maybe pick one of the two to #[arg(hide)] and comment the reasoning?
There was a problem hiding this comment.
Fixed, with hide
.well-knownpath, which required thewarg_client::FileSystemClient::new_with_config()methods to beasync;warg login <registry-url>andwarg login --registry <registry-url>(also forwarg logout);bytecodealliance.org; See discussionsFollow on work to respect HTTP cache headers.