Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

kbknapp/clap-rs

Please use https://github.com/clap-rs/clap/discussions to ask a question

People

Repo info

Activity

Mar 01 13:10

pksunkara commented #1711
Mar 01 13:09

pickfire commented #1711
Mar 01 13:07

pickfire commented #1710
Mar 01 12:14

bors[bot] commented #1710
Mar 01 12:14

CreepySkeleton commented #1710
Mar 01 12:09

CreepySkeleton commented #1710
Mar 01 12:09

CreepySkeleton commented #1710
Mar 01 12:08

pksunkara review_requested #1710
Mar 01 11:49

pickfire commented #1710
Mar 01 11:47

pksunkara commented #1711
Mar 01 11:44

pickfire opened #1711
Mar 01 11:44

pickfire labeled #1711
Mar 01 11:36

pickfire synchronize #1710
Mar 01 09:10

pickfire commented #1710
Mar 01 09:09

pickfire opened #1710
Mar 01 08:30

pksunkara commented #1655
Mar 01 08:29

pickfire commented #1655
Feb 29 16:49

bors[bot] closed #1709
Feb 29 16:49

bors[bot] commented #1709
Feb 29 16:07

pksunkara commented #1709

Denis Lisov

@tanriol

Not much. On the other hand, at the moment the amount of questions here is also rather low - maybe one in a week or even a few.

CreepySkeleton

@CreepySkeleton

Let me tell you a secret - the amount of question directed to the issue tracker is... not huge, but close to uncomfortable for some maintainers.

Diana

@DianaNites

Is there any way to do what I want TeXitoi/structopt#365? Some sort of default_occurrences_if, or a way to get default_value_if working for it?

amesgen

@amesgen

Are there plans for clap::App: Send? I think it would suffice to replace Rc by Arc here. I would be open to implementing this (behind a feature flag).

Denis Lisov

@tanriol

@amesgen What's your use case for it? Sounds to me like argument parsing usually happens well before starting additional threads, no?

amesgen

@amesgen

@tanriol Usually it does, but I use clap/structopt for parsing input commands of a chat bot. This usage seems to be intended if I interpret the comments on this correctly.

CreepySkeleton

@CreepySkeleton

@DianaNites Not that I would know about. Not with structopt at least

CreepySkeleton

@CreepySkeleton

@amesgen But do you really want to send the App instance across the boundary?

amesgen

@amesgen

@CreepySkeleton Yes, chat message processing is concurrent. Right now, I recreate the app on every message received, which is probably fine if the clap::App is small and the message frequency is low.

CreepySkeleton

@CreepySkeleton

@amesgen You should raise the issue on the tracker: https://github.com/clap-rs/clap/issues

I'm not against replacing Rc with Arc, I'm just wary it would penalize the performance for common cases in favor of corner cases. I don't see your case as very common, no offense.

Maybe we'll manage to invent an alternative solution.

CreepySkeleton

@CreepySkeleton

Also, a feature flag won't do. They are supposed to be purely additive.

Hans

@hansl

Hey guys. How y'all doing? We are using Clap for command parsing and wanted to move to v3. 2 questions; (1) can we move command to command from v2 to v3 #[derive()] (or do we have to do all at once)? and (2) can we use a function call as the default value (we have some resolution logic in some places)?

MGlolenstine

@MGlolenstine

Hey guys, I was wondering how I could set it so when my program was called without any arguments, the program would print the same as command --help. Is there a way to do it?

Also, is there a way to give command arguments default values? I'm currently checking if the variable doesn't exist and then setting it to a "default" value.

amesgen

@amesgen

@CreepySkeleton Ok, I will create an issue. Indeed, an alternative solution would be optimal. Of course, my usecase is not common (I probably should have explained my use ase upfront to prevent XY-problem-like communication). I suggested putting the Arc solution behind a feature flag exactly due to performance concerns, and I am surprised that feature flags are supposed to be only additive in clap (other libraries like tokio use feature flags for similar things (std vs parking_lot sync stuff)). Would you mind expanding on that?

Denis Lisov

@tanriol

@MGlolenstine AppSettings::ArgRequiredElseHelp, Arg::default_value - note however that these two are not compatible because the default value is considered to be present.

@amesgen In all crates feature flags are supposed to be purely additive (as in "if it compiles and I enable some other feature flag, it has to compile as well").

MGlolenstine

@MGlolenstine

@tanriol Thanks! I'm unsure how I managed to miss this.

CreepySkeleton

@CreepySkeleton

@amesgen Features are supposed to be additive in all crates because they get populated across all the dependency tree.

Imagine we've introduced a "foo" feature in clap. Your crates "banana" and "orange" depend on clap; "banana" enables "foo". Do you think "orange" depends on clap with "foo" disabled? Nope, if a feature was enabled somewhere, it ends up being enabled everywhere across the dependency graph.

This is why features are supposed to be additive.

Another explanation: https://internals.rust-lang.org/t/mutually-exclusive-feature-flags/8601/8?u=creepyskeleton

CreepySkeleton

@CreepySkeleton

Btw, all the features in tokio are additive as I see. @amesgen What were you taliking about?

amesgen

@amesgen

@CreepySkeleton Thanks for the explanation/link! This situation is indeed suboptimal, at least clap is typically used only by the final binary and not by many different intermediate libraries with different flags. The "binary only" features mentioned by withoutboats would be a perfect fit for this IMHO. I personally think that enabling App: Send behind a feature is better than preventing the (probably rather uncommon) compilation failure if two crates with and without app-send depend on clap and one crate uses a not-Send + Sync validator{_os}, but that is not for me to decide.

I was talking about the parking_lot feature of tokio, but I initially forgot that in clap, one also has to adapt the bound on F to also require Send + Sync. If this was not the case, the situation would be analogous to tokio, as the change would be purely internal. This could be fixed by also requiring Send + Sync for F even when app-send is disabled, as the public API does not depend on app-send then (I updated #1771 to mention this).

amesgen

@amesgen

One clarification: I did not consider tokio's parking_lot feature to be "additive", as it modifies internal code, rather introducing new dependencies/functions, but that is probably bikeshedding.

Pavan Kumar Sunkara

@pksunkara

Hey guys, so our support for gitter community is always supposed to be temporary. Please use https://github.com/clap-rs/clap/discussions to ask a question from now onwards. I would encourage users to also answer some questions there. And I would encourage people to point others at that if they come asking a question here. We want our community to not be fragmented anymore.

Denis Lisov

@tanriol

@pksunkara Good luck to you :-) sorry, I don't feel like watching one more space, so I'll either continue answering here or just switch to other things.

Pavan Kumar Sunkara

@pksunkara

It is one of the reasons we got discussions enabled. Because we don't want to watch more workspaces than just github.

luopan

@loloxiaoz

how to ignore extra param in clap

i use clion IDE and want to use test case, when I run test case by IDE, clap tip that

what can I do to ignore the extra param --nocapture

Denis Lisov

@tanriol

@loloxiaoz Why do you parse command-line arguments for a test at all?

stedingan

@stedingan

hello, can somebody tell me what's wrong with the following example code? https://github.com/clap-rs/clap#using-builder-pattern

if i just copy paste that snipped and do a cargo run, i get thread 'main' panicked at 'Argument names must be unique, but '' is in use by more than one argument or group',

the less verbose method of using-builder-pattern is indeed working as expected

Pavan Kumar Sunkara

@pksunkara

@stedingan That looks like a bug. Can you please create an issue?

stedingan

@stedingan

@pksunkara Yah sure. :)

cheftomahsh

@cheftomahsh

is the v3 crate separate from the main clap crate a temporary thing until the main updates to v3 or will they always be separate?

Pavan Kumar Sunkara

@pksunkara

@cheftomahsh What do you mean?

There's no v3 crate. That's published by someone else

Jonas Berlin

@xkr47

Hi, I just wanted to say thank you for a great crate! I use it in all my tools, regardless if they need arguments or not :)

Luca Barbato

@lu-zero

@CreepySkeleton if you have time today I'd need your help tracking a strange glitch with the error reporting with my patch

the check tests/ui/subcommand_on_struct.rs still returns the expected error but it also complains about not having ArgMatches in the scope, even if that I can see it is always used as ::clap::ArgMatches in the derive code...

Luca Barbato

@lu-zero

found :P

Luca Barbato

@lu-zero

now there is one in tests/ui/external_subcommand_wrong_type.rs

Luca Barbato

@lu-zero

It works but now I'm afraid I have to come up with a different way to build the arg_matches.

Luca Barbato

@lu-zero

is there already a way to get the ArgMatches even if some compulsory values are missing?