-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide data in the application domain rather than the CLI domain #2683
Comments
Sounds like this is related to #2832 |
In considering potential work for clap-rs#2683, I realized we might need a type to carry data for each of the `multiple_values`. `ArgValue` works both for that and for possible values, so we need to come up with a better name for one or both. Changing `ArgValue`s name now would be ideal since its new in clap3 and by renaming it, we can reduce churn for users. While thinking about this, I realized I regularly get these mixed up, so renaming `ArgValue` to `PossibleValue` I think will help clear things up, regardless of clap-rs#2683.
@pksunkara just captured in the Issue my thoughts from not being able to sleep last night :) I'm sure you also have some and would love to hear and see how we can synthesize the two. The only linked issue I'm seeing this directly help with is #2206. I thought it would help with #2505 but it sounds like we just repeat the same problem after exploring the idea. |
Looks good to me. I would actually make this the main product objective for 4.0. I will add more if needed once I get into this context later (which I still have in my todo) |
In considering potential work for clap-rs#2683, I realized we might need a type to carry data for each of the `multiple_values`. `ArgValue` works both for that and for possible values, so we need to come up with a better name for one or both. Changing `ArgValue`s name now would be ideal since its new in clap3 and by renaming it, we can reduce churn for users. While thinking about this, I realized I regularly get these mixed up, so renaming `ArgValue` to `PossibleValue` I think will help clear things up, regardless of clap-rs#2683.
From #2832
|
With the proposed API, if you want a path, you'd be specifying it as a |
Ahh. By "if not handled carefully", I meant "this could turn into a footgun for end users if clap doesn't handle it carefully", and that should fit the definition of "clap handling it carefully" well enough. |
@epage requested I share our usecases after a short chat. We are logging various aspects of CLI usage across the company. This is to give CLI owners an understanding of how their CLIs are used. This discoverability gives various teams the insights to improve their CLIs and see where they could improve. One example of this is the ability to see which subcommands are most often used and how long they take. This can help a team prioritise making improvements to a CLI. Saying "We saved 1000 engineers a total of 50 hours a week." is more impactful and provides incentives towards CLI improvements. Additionally this information can be useful when debugging errors as well. We are currently working towards providing automated error logging. This means that when their CLI crashes, the user doesn't have to do anything and it'll be appropriately logged and can be followed up on. Having a better understanding of the state of the CLI can be beneficial. Maybe your parsing of a CLI argument lead to the eventual error? We'd know if that data was included as metadata while logging the error. Either of these usecases would require data access in the application layer. Let me know if you have any questions. |
I had been wondering if we should offer look up functions that panic instead of returning bad type errors. To allow what @AndreasBackx brought up, we either need
|
So my current implementation offers a Progress
Deferred work
|
I was considering moving However, |
Currently, clap allows you accessing all of the values for a group. The new implementation limits that to groups where all present values are of the same type. For more background on why this was added, see #283 |
That is still blocked on another issue; I've updated the issue description to summarize what it is blocked on |
Currently, clap's API is focused on the CLI domain, with data being tracked as
OsString
with specialized helpers forString
. At the tale-end of the builder API, we provide thevalue_of_t
API. We do gloss over this in the derive API.Problems with the current approach
ArgMatches
to handle every case_os
functions but disallow non-UTF8 during validation (fix: Provide path to avoid UTF-8 panics #2677)clap_derive
callFromStr::from_str
only once per argument. #2206, try_from_str and try_from_os_str functions are called twice #3589)See also #2832, #1185
Roll out
ArgMatches
to storeBox<Any + Send + Sync + 'static>
OsString
toString
, deprecatingAllowInvalidUtf8
, gated behind a feature flagOther considerations / open questions
multiple_values
, users also have to setdefault_values
,value_names
, andvalue_hints
, should we followpossible_values
and avoid users passing in parallel arrays?Display
clap_derive
currently punts on this by providing both adefault_value
anddefault_value_t
where the latter has to supportDisplay
and it gets forwarded todefault_value
, see feat(derive): Specify defaults by native expressions #2635AllowInvalidUtf8
Any
, etc.trait ValueParser
and provide astruct BoxedValueParser
that contains an enum for common function-pointer signatures (wrapped with converters for the error types) and people can explicitly construct aBoxedValueParser
for their custom typeclap_derive
ArgMatches
API to be more map-likeArgMatches
#1206remove
function would allowclap_derive
to move values, instead of clone them.default_value
:ValueHint
: if we can detect and set a default forPath
that would provide a better default experiencevalue_name
for named arguments: the default (of--name <name>
) is redundant. If we could provide type related defaults (e.g.PATH
forPathBuf
,NUM
for numbers), it would also provide a better default experienceOriginal
Basically, there are two things that need to be solved here.
I have to dig into the code to write a longer description of issues with the current behaviour and design.
clap_derive
callFromStr::from_str
only once per argument. #2206FromStr
,TryFrom<&OsStr>
, etc., in clap_derive #2298#[clap(parse(try_from_str))]
doesn't usetry_from(&str)
#2437See also #2832
The text was updated successfully, but these errors were encountered: