profile
viewpoint
Kevin K. kbknapp @BrilliantSolutionsInc DC, USA https://kbknapp.dev I love to code, skydive, and do the things.

kbknapp/cargo-outdated 511

A cargo subcommand for displaying when Rust dependencies are out of date

kbknapp/cargo-graph 196

A cargo subcommand for creating GraphViz DOT files and dependency graphs

kbknapp/cargo-count 117

a cargo subcommand for counting lines of code in Rust projects

kbknapp/cargo-extras 36

A collection of cargo subcommands

clap-rs/clap_derive 30

Custom derive for clap.

clap-rs/term_size-rs 30

Functions for determining terminal sizes in Rust

kbknapp/Clapp-py 10

A small library for quickly and easily creating command line applications in python.

clap-rs/clap-book 9

A book detailing how to build command line applications in Rust

clap-rs/clap-validators 4

Predefined argument validators that can be used with clap-rs

clap-rs/clap-www 3

clap.rs website

issue commentlibpnet/libpnet

Segfault in icmp send

I took a look at this out of curiosity and it looks like this is because for some reason Rust is optimizing out the rx local variable in cloudflare-ping/src/ping_core.rs:304

0xd34b33f

comment created time in 6 hours

push eventkbknapp/dotfiles

Kevin K

commit sha fd8f0d5f9bc63aa9552bd8eee385eba49aff2b42

adds watchexec to rust apps

view details

push time in 8 days

startedwatchexec/watchexec

started time in 8 days

push eventkbknapp/dotfiles

Kevin K

commit sha 776f98048cec10f514f70b3d4e3bfa7d90ceb036

adds password expr commands to navi

view details

push time in 9 days

push eventkbknapp/dotfiles

Kevin K

commit sha 143a82eb711b0c54ae725f11aa14146b78039871

adds flatseal to flatpak apps

view details

push time in 9 days

push eventkbknapp/dotfiles

Kevin K

commit sha 6da72771537efe5e6bba465abbec2105a7539cc6

adds cargo-udeps

view details

push time in 16 days

push eventkbknapp/dotfiles

Kevin K

commit sha a9566a554da4f3df9bafaf9078a98d3862c6efc1

adds more cargo installed binaries

view details

Kevin K

commit sha 9cb74630acebf33c0cbe0b071f17a4c168b496e1

adds ss cheats

view details

Kevin K

commit sha 260d937d63f6c01fa74eb6bfbe1fbfefe98038eb

adds netstat cheats

view details

Kevin K

commit sha 3c93bebc769dedb76a0aabe3581d1ad6f234d3ce

adds find cheat to delete empty dirs

view details

Kevin K

commit sha 467b0e5cb492d7b3e380b52bc2458a91fd7420ac

adds more network info cheats

view details

push time in 16 days

issue commentFRRouting/frr

frr.service is deleting default routes on Ubuntu 18.04

Sorry to necro-bump but we've noticed something super similar as well but with FRR 7.2 on Ubuntu 18.04. To be fair, we can't say for sure it's FRR, but the routing table is dropping and it sounds similar.

shibumi

comment created time in 17 days

startedspieglt/whatfiles

started time in 24 days

issue openedlibpnet/libpnet

Is MutablePacket::clone_from sound?

Possibly related to #142

I was going through some of the intro docs to this lib as it looks like it could fit for an upcoming project :smile:

However, in example number one it shows use of MutablePacket::clone_from, so I dove in to see how it was written.

I could be wrong, as the idiosyncrosis of unsafe are not my forte, however I don't believe the function as written is sound for two reasons:

  • No invariant is enforced such that either T: Copy or T isn't used again
  • Is it common to make a packet from another packet type? I.e. can I make an Ethernet packet from an Arp packet? The only invariant enforced is that the packet being created have a larger buffer than the other packet.

The Rust docs stress that using std::ptr::copy_nonoverlapping where T: !Copy is not sound if T is read from again. Nothing in the current function enforces either T: Copy or that T is not used again. Since non of the types implementing MutablePacket should be Copy, I think this means either marking the function and/or trait unsafe, or taking T by value.

As for the making of a packet from a different packet type, I thnk the fix is just to make the signature fn clone_from(&mut self, other: &Self) (if ignoring the comments about Copy for the moment). This function is also covariant with respect to T, but if it's true you don't want multiple packet types, you'd want it to be invariant with respect to T.

Also, I could be wrong here, so hopefully it sparks a discussion!

created time in a month

push eventkbknapp/crev-proofs

Kevin K

commit sha 369b70985d009dc039c97465708cfd9a0ff74608

Add trust for VylyTuk8CMGqIxgHixWaqfiUn3xZyzOA1wFrQ0sR1As

view details

Kevin K

commit sha 2a3d391051c4c95f399007c1addafce3840f0890

Add trust for FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE

view details

push time in a month

fork kbknapp/crev-proofs

Crev proof repository

fork in a month

startedlibpnet/libpnet

started time in a month

pull request commentclap-rs/clap

makes validators opt-out

Turns out I'll need to go back to the drawing board. A case of two things named similar, but not doing the same thing. I'll re-open when I've had a chance to actually make validators opt-out :wink:

kbknapp

comment created time in a month

PR closed clap-rs/clap

makes validators opt-out

Validators are not always used, in fact it might be fair to say they're rarely used. However they make up a large portion of the binary size. This PR feature gates them with a new feature validators which is part of the default feature set.

Setup

// src/main.rs
use clap::{App, Arg};
fn main() {
    let matches = App::new("test")
        .arg(Arg::new("foo").short('f').long("foo").default_value("99"))
        .arg(Arg::new("bar").short('b').long("bar"))
        .get_matches();

    let foo = matches.value_of("foo").unwrap();
    println!("foo: {}", foo);
}

Before

NOTE: this is without the derive feature

cargo bloat --release --crates | head
    Finished release [optimized] target(s) in 0.01s
    Analyzing target/release/fake

 File  .text     Size Crate
 9.3%  58.0% 327.3KiB clap
 4.5%  28.1% 158.4KiB std
 1.7%  10.3%  58.3KiB [Unknown]
 0.1%   0.6%   3.3KiB indexmap
 0.1%   0.5%   3.1KiB strsim
 0.1%   0.3%   1.8KiB termcolor
 0.0%   0.3%   1.6KiB textwrap
 0.0%   0.3%   1.5KiB fake
 0.0%   0.0%      41B os_str_bytes

Top 5 largest functions:

cargo bloat --release -n 5 | head
    Finished release [optimized] target(s) in 0.01s
    Analyzing target/release/fake

 File  .text     Size     Crate Name
 1.0%   6.2%  35.3KiB      clap clap::parse::parser::Parser::get_matches_with
 0.5%   3.3%  18.4KiB      clap clap::parse::validator::Validator::validate
 0.5%   3.0%  17.1KiB      clap clap::output::help::Help::write_help
 0.5%   3.0%  17.0KiB      clap clap::output::help::Help::write_arg
 0.3%   1.9%  10.7KiB [Unknown] add_ranges
13.0%  80.9% 456.8KiB           And 1216 smaller methods. Use -n N to show more.
16.0% 100.0% 564.6KiB           .text section size, the file size is 3.4MiB

After (when opt-ing out of validators)

cargo bloat --release --crates | head
    Finished release [optimized] target(s) in 0.01s
    Analyzing target/release/fake

 File  .text     Size Crate
 7.7%  52.5% 265.4KiB clap
 4.7%  31.9% 161.2KiB std
 1.7%  11.5%  58.3KiB [Unknown]
 0.1%   0.6%   3.3KiB indexmap
 0.1%   0.6%   3.1KiB strsim
 0.1%   0.4%   1.8KiB termcolor
 0.0%   0.3%   1.6KiB textwrap
 0.0%   0.3%   1.5KiB fake
 0.0%   0.0%      41B os_str_bytes

Top 5 largest functions:

cargo bloat --release -n 5 | head
   Compiling clap v3.0.0-beta.1 (/storage/Projects/clap)
   Compiling fake v0.1.0 (/storage/Projects/fake)
    Finished release [optimized] target(s) in 4.97s
    Analyzing target/release/fake

 File  .text     Size     Crate Name
 1.0%   7.1%  35.8KiB      clap clap::parse::parser::Parser::get_matches_with
 0.5%   3.4%  17.1KiB      clap clap::output::help::Help::write_help
 0.5%   3.4%  17.0KiB      clap clap::output::help::Help::write_arg
 0.3%   2.1%  10.7KiB [Unknown] add_ranges
 0.3%   2.0%  10.3KiB [Unknown] read_line_info
11.8%  80.2% 405.3KiB           And 1157 smaller methods. Use -n N to show more.
14.7% 100.0% 505.0KiB           .text section size, the file size is 3.4MiB

Relates to #1365

+21 -5

2 comments

6 changed files

kbknapp

pr closed time in a month

pull request commentclap-rs/clap

makes validators opt-out

It looks like one of the tests that's failing should be using a different command.

The current command:

$ cargo test --target x86_64-unknown-linux-gnu --no-default-features --features std cargo -p clap:3.0.0-beta.1

Correct:

$ cargo test --target x86_64-unknown-linux-gnu --no-default-features --features "std cargo" -p clap:3.0.0-beta.1

Also correct:

$ cargo test --target x86_64-unknown-linux-gnu --no-default-features --features std,cargo -p clap:3.0.0-beta.1
kbknapp

comment created time in a month

issue commentclap-rs/clap

Website is not linking back to github repo

I'm fine with someone working on a refactor. I just don't personally have time to work on it. The current implementation is just a barebones wordpress site. It used to have a lot more content, but due to some shenanigans the old site was lost and I stood up just a bare bones version.

I'll fix the link on the current site so we can close this issue, but I'm good with opening an issue to refactor the site.

erdii

comment created time in a month

PR opened clap-rs/clap

makes validators opt-out

Validators are not always used, in fact it might be fair to say they're rarely used. However they make up a large portion of the binary size. This PR feature gates them with a new feature validators which is part of the default feature set.

// src/main.rs
use clap::{App, Arg};
fn main() {
    let matches = App::new("test")
        .arg(Arg::new("foo").short('f').long("foo").default_value("99"))
        .arg(Arg::new("bar").short('b').long("bar"))
        .get_matches();

    let foo = matches.value_of("foo").unwrap();
    println!("foo: {}", foo);
}

NOTE: this is without the derive feature

cargo bloat --release --crates | head
    Finished release [optimized] target(s) in 0.01s
    Analyzing target/release/fake

 File  .text     Size Crate
 9.3%  58.0% 327.3KiB clap
 4.5%  28.1% 158.4KiB std
 1.7%  10.3%  58.3KiB [Unknown]
 0.1%   0.6%   3.3KiB indexmap
 0.1%   0.5%   3.1KiB strsim
 0.1%   0.3%   1.8KiB termcolor
 0.0%   0.3%   1.6KiB textwrap
 0.0%   0.3%   1.5KiB fake
 0.0%   0.0%      41B os_str_bytes
cargo bloat --release -n 5 | head
    Finished release [optimized] target(s) in 0.01s
    Analyzing target/release/fake

 File  .text     Size     Crate Name
 1.0%   6.2%  35.3KiB      clap clap::parse::parser::Parser::get_matches_with
 0.5%   3.3%  18.4KiB      clap clap::parse::validator::Validator::validate
 0.5%   3.0%  17.1KiB      clap clap::output::help::Help::write_help
 0.5%   3.0%  17.0KiB      clap clap::output::help::Help::write_arg
 0.3%   1.9%  10.7KiB [Unknown] add_ranges
13.0%  80.9% 456.8KiB           And 1216 smaller methods. Use -n N to show more.
16.0% 100.0% 564.6KiB           .text section size, the file size is 3.4MiB
cargo bloat --release --crates | head
    Finished release [optimized] target(s) in 0.01s
    Analyzing target/release/fake

 File  .text     Size Crate
 7.7%  52.5% 265.4KiB clap
 4.7%  31.9% 161.2KiB std
 1.7%  11.5%  58.3KiB [Unknown]
 0.1%   0.6%   3.3KiB indexmap
 0.1%   0.6%   3.1KiB strsim
 0.1%   0.4%   1.8KiB termcolor
 0.0%   0.3%   1.6KiB textwrap
 0.0%   0.3%   1.5KiB fake
 0.0%   0.0%      41B os_str_bytes
cargo bloat --release -n 5 | head
   Compiling clap v3.0.0-beta.1 (/storage/Projects/clap)
   Compiling fake v0.1.0 (/storage/Projects/fake)
    Finished release [optimized] target(s) in 4.97s
    Analyzing target/release/fake

 File  .text     Size     Crate Name
 1.0%   7.1%  35.8KiB      clap clap::parse::parser::Parser::get_matches_with
 0.5%   3.4%  17.1KiB      clap clap::output::help::Help::write_help
 0.5%   3.4%  17.0KiB      clap clap::output::help::Help::write_arg
 0.3%   2.1%  10.7KiB [Unknown] add_ranges
 0.3%   2.0%  10.3KiB [Unknown] read_line_info
11.8%  80.2% 405.3KiB           And 1157 smaller methods. Use -n N to show more.
14.7% 100.0% 505.0KiB           .text section size, the file size is 3.4MiB

Relates to #1365

+21 -5

0 comment

6 changed files

pr created time in a month

push eventclap-rs/clap

CreepySkeleton

commit sha d6603c739d30543eaab19bb7c0f13fb0a3d53a5a

Limit text wrapping to 100 symbols by default

view details

bors[bot]

commit sha 229cbbf7a2dc71c2af980164da84b227012cbb6c

Merge #1950 1950: Limit text wrapping to 100 symbols by default r=pksunkara a=CreepySkeleton Co-authored-by: CreepySkeleton <creepy-skeleton@yandex.ru>

view details

Kevin K

commit sha a4586449867dc10af8153792ddfa414f92880c86

chore(.gitignore): adds ctags files to ignores

view details

Kevin K

commit sha 9bf762e2c7f2616084650a5d96d31e6885d37a1e

perf(Validators): makes validators opt-out A new feature is added `validators` which is part of the default feature set, but can be opted out by removing it when not using. This greatly reduces the clap binary size. **NOTE:** this is without the `derive` feature ```rust // src/main.rs use clap::{App, Arg}; fn main() { let matches = App::new("test") .arg(Arg::new("foo").short('f').long("foo").default_value("99")) .arg(Arg::new("bar").short('b').long("bar")) .get_matches(); let foo = matches.value_of("foo").unwrap(); println!("foo: {}", foo); } ``` ``` cargo bloat --release --crates | head Finished release [optimized] target(s) in 0.01s Analyzing target/release/fake File .text Size Crate 9.3% 58.0% 327.3KiB clap 4.5% 28.1% 158.4KiB std 1.7% 10.3% 58.3KiB [Unknown] 0.1% 0.6% 3.3KiB indexmap 0.1% 0.5% 3.1KiB strsim 0.1% 0.3% 1.8KiB termcolor 0.0% 0.3% 1.6KiB textwrap 0.0% 0.3% 1.5KiB fake 0.0% 0.0% 41B os_str_bytes ``` ``` cargo bloat --release -n 5 | head Finished release [optimized] target(s) in 0.01s Analyzing target/release/fake File .text Size Crate Name 1.0% 6.2% 35.3KiB clap clap::parse::parser::Parser::get_matches_with 0.5% 3.3% 18.4KiB clap clap::parse::validator::Validator::validate 0.5% 3.0% 17.1KiB clap clap::output::help::Help::write_help 0.5% 3.0% 17.0KiB clap clap::output::help::Help::write_arg 0.3% 1.9% 10.7KiB [Unknown] add_ranges 13.0% 80.9% 456.8KiB And 1216 smaller methods. Use -n N to show more. 16.0% 100.0% 564.6KiB .text section size, the file size is 3.4MiB ``` ``` cargo bloat --release --crates | head Finished release [optimized] target(s) in 0.01s Analyzing target/release/fake File .text Size Crate 7.7% 52.5% 265.4KiB clap 4.7% 31.9% 161.2KiB std 1.7% 11.5% 58.3KiB [Unknown] 0.1% 0.6% 3.3KiB indexmap 0.1% 0.6% 3.1KiB strsim 0.1% 0.4% 1.8KiB termcolor 0.0% 0.3% 1.6KiB textwrap 0.0% 0.3% 1.5KiB fake 0.0% 0.0% 41B os_str_bytes ``` ``` cargo bloat --release -n 5 | head Compiling clap v3.0.0-beta.1 (/storage/Projects/clap) Compiling fake v0.1.0 (/storage/Projects/fake) Finished release [optimized] target(s) in 4.97s Analyzing target/release/fake File .text Size Crate Name 1.0% 7.1% 35.8KiB clap clap::parse::parser::Parser::get_matches_with 0.5% 3.4% 17.1KiB clap clap::output::help::Help::write_help 0.5% 3.4% 17.0KiB clap clap::output::help::Help::write_arg 0.3% 2.1% 10.7KiB [Unknown] add_ranges 0.3% 2.0% 10.3KiB [Unknown] read_line_info 11.8% 80.2% 405.3KiB And 1157 smaller methods. Use -n N to show more. 14.7% 100.0% 505.0KiB .text section size, the file size is 3.4MiB ``` Relates to #1365

view details

Kevin K

commit sha 47434853a58c6edd894875e6a8635e95d9ae2928

tests(validators): feature gates validator tests

view details

push time in a month

create barnchclap-rs/clap

branch : opt-out-validator

created branch time in a month

pull request commentclap-rs/clap

Limit text wrapping to 100 symbols by default

There may be some tests that used 120 width...but I can't remember off the top of my head. We'll see shortly I guess!

CreepySkeleton

comment created time in a month

pull request commentclap-rs/clap

Limit text wrapping to 100 symbols by default

I'm :+1: once checks pass.

CreepySkeleton

comment created time in a month

issue commentclap-rs/clap

Sub-optimal help wrapping with long messages by default

Linus Torvalds the issue

Sorry, it was late and I should have clarified I didn't post that link because I agree or disagree, just because it was some recent discussion on the topic :stuck_out_tongue_winking_eye:

kbknapp

comment created time in a month

pull request commentclap-rs/clap

Unify name and arg order scheme

Then perhaps maybe a look through grep.app to see which is more common (requires_if or required_if) would help. It's also possible to keep both, so long as the internal representation is the same between the two and docs do a better job of explaining why both exists and when to pick one over the other.

CreepySkeleton

comment created time in a month

pull request commentclap-rs/clap

Unify name and arg order scheme

I'm just questioning usefulness of this method because it can be trivially replaced with required_if

Ah ok, I misunderstood your question. Yes I'd agree with that. I'd be OK removing requires_if since it's the more confusing of the two.

The only counterpoint I can think of is if you have one argument who affects many others, it's easier to make all those changes in one place than at each affected argument. I.e. single source instead of multi destination.

CreepySkeleton

comment created time in a month

issue commentclap-rs/clap

Auto-generate manpage, help docs, etc.

Admin Note

The discussion here got a little heated and derailed, which is totally possible and common with online discussions.

Just a reminder for everyone to remain civil, even when differences of opinion exist. We can, and I expect us to debate technical issues, but those debates must remain calm and professional.

This issue will remain locked for the next 48 hours to allow everyone involved a chance to take a break and perhaps consider other angles. Personally, I think this is a great time to attempt to see something from another's point of view.

One final note, as we're discussing technical details this thread is already very long so lets do our best to keep the discussion related to this issue, and within the realm of what is actionable by clap code. If there are other debates to be had, lets move them to chat, GH discussions, or dedicated issues here/issue trackers on other projects.

I appreciate the passion everyone is displaying for this feature, I want it to land and I want a design that pushes this library forward. I think we all want that :smile:

joshtriplett

comment created time in a month

IssuesEvent

pull request commentclap-rs/clap

Unify name and arg order scheme

The historical context is it should be arg, value, but requires_if (note s) doesn't have an arg as the arg is actually self. The arg being referenced in requires_if is not associated with the value.

Written in long form it'd be:

required_if(other_arg, other_arg_value)

requires_if(self_value,  other_arg_to_require)
CreepySkeleton

comment created time in a month

PublicEvent

push eventkbknapp/dotfiles

Kevin K

commit sha 73177c6febe0c8b9694de0fe9a1a8a1836cb1177

adds vimwiki

view details

push time in a month

push eventkbknapp/dotfiles

Kevin K

commit sha 70cfab4a56e63ba9eb609e37ef8456368f263b28

adds required neovim plugin packages

view details

Kevin K

commit sha 384ea78d565b2ca595c899873e4c7b8fe4efb8f1

adds scratchpad support

view details

Kevin K

commit sha 2c61f4ecb7178417bafa7c9517285b92d94f8db1

Merge branch 'master' of github.com:kbknapp/dotfiles

view details

push time in a month

issue commentrust-lang/cargo

Make `cargo outdated` part of cargo itself

cc @deg4uss3r

behnam

comment created time in a month

issue commentclap-rs/clap

Subcommand bin_name on Windows contains ".exe" in the middle instead of at the end (or not at all)

The first element of the iterator (if NoBinaryName wasn't set)

The purpose of that setting was to start parsing immediately as arguments, instead of skipping argv[0]. i.e. such as a REPL or other prompt where the consumer code is continually passing an argv direct to clap that doesn't include the binary.

which is supposed to be used "as if" it was argv[0]

That's the incorrect bit :wink: clap assumes the binary name was set manually when NoBinaryName is used, it doesn't re-interpret argv[0] as a new binary name.

Arnavion

comment created time in a month

issue commentclap-rs/clap

[Question/Feature] Is There a Way to Make Args that Behave Like `--help`

Traditionally the only way to do something like this was to make --doc a global argument, use required_unless and then in consumer code check for --doc prior to actually doing any real work.

Since exclusive is a 3.x addition, we could downgrade it to override all other arguments instead of hard conflict and error. Reason being, we can't enforce process ending (minus error) without some kind of handler which is still undecided. cc @CreepySkeleton @pksunkara

zicklag

comment created time in a month

issue commentclap-rs/clap

Placing `--` before a subcommand fails with a confusing error

Basically, we shouldn't include this line:

If you tried to supply `stash` as a PATTERN use `-- stash`

if -- was used.

DemiMarie-parity

comment created time in a month

issue commentclap-rs/clap

Placing `--` before a subcommand fails with a confusing error

Upgrading to 3.0-beta.1 provides a better, but still not perfect message:

cargo run -- -- stash
   Compiling ledgeracio v0.1.0 (/home/kevin/.tmp/ledgeracio)
    Finished dev [unoptimized + debuginfo] target(s) in 5.98s
     Running `target/debug/ledgeracio -- stash`
error: Found argument 'stash' which wasn't expected, or isn't valid in this context

If you tried to supply `stash` as a PATTERN use `-- stash`

USAGE:
    ledgeracio [FLAGS] [OPTIONS] <SUBCOMMAND>

For more information try --help
DemiMarie-parity

comment created time in a month

pull request commentclap-rs/clap

Unify name and arg order scheme

We should add this (along with other breaking changes) to the breaking changes log we know what to advertise as having changed when upgrading.

CreepySkeleton

comment created time in a month

Pull request review commentclap-rs/clap

Unify name and arg order scheme

 struct Opt {     #[clap(long("values"))]     values: Vec<i32>, -    #[clap(name = "FILE", requires_if("FILE", "values"))]+    #[clap(name = "FILE", requires_if_eq("values", "FILE"))]

Should be (arg, value), no?

CreepySkeleton

comment created time in a month

PR closed clap-rs/clap

Create FUNDING.yml

I recently released cargo-fund, and noticed that while there is sponsorship information in this repo, but it's not yet encoded in a machine-readable way. Adding this metadata will add a "Sponsor" button to the repo, and allow cargo-fund to show the project's sponsorship link. For more about this file format, see the Github docs.

I also noticed that this URL doesn't appear to work currently, but there is still sponsor information on the front page of clap.rs. Feel free to modify this if there's now a more appropriate URL.

<!-- If your PR closes some issues, please write Closes #XXXX where XXXX is the number of the issue you want to fix. Each issue goes on it's own line. -->

+1 -0

5 comments

1 changed file

acfoltzer

pr closed time in a month

pull request commentclap-rs/clap

Create FUNDING.yml

Ideally, we should ask the patreon's to move also but it's upto you since it looks like a personal patreon rather than clap project as a whole.

Yeah I wouldn't mind having a clap focused patreon, although if we did that'd probably lean towards Github Sponsors only to not have to manage tons of different locations, payouts, etc.

I say lets move this discussion to the admin area of the repo, unless we specifically need opinions from clap consumers, which could comment in an issue.

I'm going to close this PR for now, but @acfoltzer once we have our sponsorship stuff sorted out I'm open to including it via cargo-fund :+1:

acfoltzer

comment created time in a month

pull request commentclap-rs/clap

Create FUNDING.yml

Can you outline the current budget needed?

Item Cost (USD) When
Domain 31.85 (29 EUR) Yr
Whois (domain) 5.49 (5 EUR) Yr
clap.rs 10 Mo
builder 15 Mo

Which gives a grand total of $28-ish per month, so not bad. I've also had some one time costs like stickers, but those aren't common.

acfoltzer

comment created time in a month

pull request commentclap-rs/clap

Create FUNDING.yml

@pksunkara I'm not familiar with OpenCollective other than hearing it in passing from time to time. Currently, the only way we have to sponsor clap is through my personal Patreon or direct payments via PayPal/crypto/etc. I believe we might also available to do GitHub sponsors, but I haven't looked into that for this org or the details of such. The Patreon currently pays a portion of the website/domain costs, but the rest I just pay out of pocket.

Ideally, if clap were to be better funded I'd like to pay out regularly to the people putting in the effort and work.


As for this PR, the page listed is 404 since the back end of clap.rs changed, I hadn't replaced the sponsorship page. So we'd either need to change the location, or have a larger discussion about funding (probably in the issues section) before a merge.

Side note: I wasn't aware of cargo-fund and that's a very cool idea :smile:

acfoltzer

comment created time in a month

push eventkbknapp/dotfiles

Kevin K

commit sha 55c8505de6608cb1399c1416d747d44df8d7ef13

moves alacritty to new repo location

view details

Kevin K

commit sha 06bdd83a89132f36b76aa92b0a6315d9718a2db8

uses apt-get over apt

view details

Kevin K

commit sha 6bd7ad4b214780db8c94826935323109ac4c3b93

adds yubikey to ubuntu

view details

Kevin K

commit sha 1eb871ed5f6133ded3ab5dcbd3b7927a66baed32

fixes ubuntu post install

view details

Kevin K

commit sha 9cf6bc700e031cbfe37bdafb7aba2758a3aaa27c

updates zshrc to not use sccache unless it exists

view details

push time in a month

push eventkbknapp/dotfiles

Kevin K

commit sha 4683a08a73fd02e3db6bd0459b368571582761cb

adds ubuntu i3 (kde)

view details

Kevin K

commit sha 44f13761b0f31b5f63a02271d894883187e223f7

removes fonts not in ubuntu 20.04

view details

Kevin K

commit sha 2a99765e99eb67f1bf79987b780abd4caa45c8b0

Merge branch 'master' of github.com:kbknapp/dotfiles

view details

push time in a month

push eventkbknapp/dotfiles

Kevin K

commit sha e6e8a4a69433903f6d73aa76548747a5dde3f126

adds ethtool cheats

view details

Kevin K

commit sha 3392f098396090f02a54af92265656eabe5de664

Merge branch 'master' of github.com:kbknapp/dotfiles

view details

push time in 2 months

push eventkbknapp/dotfiles

Kevin K

commit sha b900197067db52947497fd27042824649c3ba982

adds git-absorb to rust applications

view details

push time in 2 months

push eventkbknapp/dotfiles

Kevin K

commit sha 849d7a31eac94043fd189e5086d86bdb8a0694a4

adds handlr to rust applications

view details

push time in 2 months

startedalegrey91/systemd-service-hardening

started time in 2 months

push eventkbknapp/dotfiles

Kevin K

commit sha 262ebc1dc3f6322168796edf43eeb5cad70cf500

adds cargo-deps instead of cargo-graph

view details

push time in 2 months

issue commentclap-rs/clap

Binary size could be smaller

I think using indexmap in place of vec_map would make the performance worse. And we need indexmap for ordered map IIRC.

That's entirely possible. I haven't done any investigating on the matter yet.

There was a PR in the v2 commit history which removed bitflags but then you reverted it back @kbknapp. Not sure what happened but it was around 2 yrs ago.

That was switching bitflags for a HashSet which had a significant negative performance impact which was the reasons for the revert.

smklein

comment created time in 2 months

issue commentclap-rs/clap

Binary size could be smaller

If we take the case of vec_map, my question is why do we want to make it optional? Shouldn't it be either including it completely or removing it completely? I think this is basic question we want to answer first.

My understanding is there are several concerns that can also overlap with each other, and not everyone has the same concerns. As mentioned above, some of those include:

  • Binary Size
  • Compile Time
  • Transitive Deps (which repeats points 1-2 for each dep)

Adding a dep can have negative impacts on points 1 and 2, or both. Some people care about point 1, some people about point 2, and some about both. So if we consider either point a deps "cost" we have to weigh that cost against it's benefits (usually performance, or lower maintenance burden for us directly).

This is what I was trying to say earlier, we have to weigh any cost (including the subjective ones) against the objective benefit.

The reason for making it optional and not a binary include or not include is because people have various requirements. Some may not care about the binary size, or increased compile time if the feature provided is worth the cost, but since some do care we need a way to allow our consumers the same choices we're making at the library level.

For vec_map which is a self contained crate and no transitive deps, I would want to look at exactly what perf gains we get, compared with binary size/compile times. Add to that, since we pulled in IndexMap, perhaps we can use that instead and remove one or the other entirely? I haven't looked lately, so that may not be feasible.


To address the comments per dep from @BurntSushi :+1:

  • bitflags - I hadn't really considered just pulling in the logic of bitflags...but now that you say it I'm sure it's actually simple subset since we don't particularly care about the macros, etc. just the functionality.
  • textwrap - the hard part with this one is this dep helps us wrap at word boundaries intelligently. But perhaps making it optional for those that will manually wrap their help strings anyways.
  • unicode-width - I also like the idea of providing a, "I only use ASCII args/help strings (values excluded), so turn off all extra deps related to handling Unicode logic" flag
  • indexmap - Might be able to combine with vec_map, or relook at our exact use case. I need to familiarize myself with the code again.
  • os_str_bytes - This is probably staying for the time being. Clap is pretty much written with idea we use OsStr(ing) internally everywhere, and only assume/use UTF-8 at the consumer demarcation point. I've toyed with the idea of bstr since all we really care about is bytes, but not done enough research to see what overlap, if any, bstr and os_str_bytes have or which would be the best fit.
  • vec_map - Addressed in other comments. I just want to make sure we're getting a good cost:benefit ratio otherwise we may drop it entirely.
smklein

comment created time in 2 months

issue commentclap-rs/clap

Binary size could be smaller

Thank you for the detailed response! Before I can finish reading the comment and add any thoughts, let me address something real quick as a moderation note:

from reading the comments, it seems like there's an undercurrent of counter-productive "us vs them." If I'm coming from (your perspective) the "anti-dependency" camp and you already believe that you can't sell clap to me

I want to be very clear with everyone reading these messages (especially including the clap team) that this is not what I want to portray or the tone I want to encourage. Internet communications via text are hard, especially when we start considering native languages and such.

I just want to be clear that the clap team is on the same page of, there is no "us vs them" and all opinions are welcome! We have differences of priorities and how to achieve those priorities, but all opinions are valid within this discussion. Ultimately the clap team will have to make a decision on which priority and implementation strategy to go with, but through discussions and issues like these my goal is to take all opinions in, consider them carefully, and make a decision that is best for clap and all consumers (current and future).


...now back to reading :smile:

smklein

comment created time in 2 months

CommitCommentEvent

issue commentclap-rs/clap

Decide on cherry picking commits from v2

ef92e2b is not implemented on v3, but I also don't have strong feelings about it. It changes the error message when suggestions are enabled. The old v2 and current v3 implementation will suggest a subcommand with the appropriate args even when no subcommand is used. Whereas that commit only suggest a subcommand when that subcommand is used.

I think the current v3 (and old v2) is fine, but if we want to cherry pick it across (and I'm not sure it can be cleaning picked) that's fine too.

pksunkara

comment created time in 2 months

issue commentclap-rs/clap

Compute argument possible values based on other arguments

Also potentially related #1880

fbecart

comment created time in 2 months

issue commentclap-rs/clap

Add display_after for easier arg positioning in --help message

I actually use it. The problem was that it don't play well with structopt flattening, more specifically it doesn't allow to move argument into separate struct while keeping its order in --help message. This could be easily structopt problem, however it also seems that it occurs because current display_order functionality in clap is somehow limited.

Aaah ok, I understand. Yeah to me that sounds like either a feature/bug we could work on as part of clap_derive (what was structopt).

I'm open to others opinions as well, but even when flattening the order should be preserved. That sounds like a new issue to me, or perhaps we re-name this issue and update the OP with this new constraint/requirement.

I60R

comment created time in 2 months

push eventkbknapp/dotfiles

Kevin K

commit sha ee1b4f51027df7c825175ef3ee0742e4b3507ae1

adds a proxy ssh cheat

view details

push time in 2 months

release clap-rs/clap

v2.33.1

released time in 2 months

created tagclap-rs/clap

tagv2.33.1

A full featured, fast Command Line Argument Parser for Rust

created time in 2 months

push eventclap-rs/clap

Kevin K

commit sha bc3291db8e2d44e3171d42fe59bdaf0f07e24dce

chore: increase version on v2 branch

view details

Kevin K

commit sha 7ac16ac5c7ee7bfcf7b9a083cf9f4e1e99a4ed65

chore: increase ver ref in lib.rs

view details

Kevin K

commit sha ffb8d552c2e9a49da50d93577345779fb92c34a1

Merge pull request #1917 from clap-rs/v2.33.1 v2.33.1

view details

push time in 2 months

delete branch clap-rs/clap

delete branch : v2.33.1

delete time in 2 months

PR merged clap-rs/clap

Reviewers
v2.33.1 M: release

Once merged (assuming no :-1: ) I'll release v2.33.1 on crates.io and this repos release tab.

+18 -3

2 comments

3 changed files

kbknapp

pr closed time in 2 months

pull request commentclap-rs/clap

v2.33.1

Sorry, that version check gets me every time.

No need to re-review unless changes requested:

Current status 3/5 admin :+1: (4/5 required for merge):

  • [x] @kbknapp
  • [x] @pksunkara
  • [x] @TeXitoi
  • [ ] @CreepySkeleton
  • [ ] @Dylan-DPC
kbknapp

comment created time in 2 months

push eventclap-rs/clap

Kevin K

commit sha 7ac16ac5c7ee7bfcf7b9a083cf9f4e1e99a4ed65

chore: increase ver ref in lib.rs

view details

push time in 2 months

pull request commentclap-rs/clap

prevent some panics when parsing invalid Unicode on Windows

@oconnor663 watch #1917 for progress on the release

oconnor663

comment created time in 2 months

PR opened clap-rs/clap

Reviewers
v2.33.1 M: release

Once merged (assuming no :-1: ) I'll release v2.33.1 on crates.io and this repos release tab.

+17 -2

0 comment

2 changed files

pr created time in 2 months

create barnchclap-rs/clap

branch : v2.33.1

created branch time in 2 months

pull request commentclap-rs/clap

prevent some panics when parsing invalid Unicode on Windows

My mistake. Thanks :stuck_out_tongue_winking_eye:

oconnor663

comment created time in 2 months

pull request commentclap-rs/clap

implement Arg::short_alias and Arg::short_aliases

Looks good to me, once @pksunkara gives the green light from his requested changes I'm :+1: for merge.

connorskees

comment created time in 2 months

pull request commentclap-rs/clap

prevent some panics when parsing invalid Unicode on Windows

Sorry for the wait! This looks good to me, and thank you for the thoughtful and complete documentation and tests, those are very much appreciated!

Side note, I'd never considered using cfged scopes with an early return before, nice idea!

bors r+

oconnor663

comment created time in 2 months

startedmre/idiomatic-rust

started time in 2 months

push eventkbknapp/dotfiles

Kevin K

commit sha d8a2b590fda6eca1fef46e5f1eb9d412a9a30b9f

adds better markdown support

view details

Kevin K

commit sha d4a6b909162a0b196c3a69c53f0b7cc903e89000

adds some seccomp cheats

view details

Kevin K

commit sha 7744826b8eb3c438492a44c908b956db22353489

adds some strace cheats

view details

push time in 2 months

push eventkbknapp/dotfiles

Kevin K

commit sha 8298e0752c4a38af5c494046435f0bfdde0e9aef

adds cargo-sweep

view details

Kevin K

commit sha 52a38afc4b1150859212dcdd5e7b0fd3c8f6c75b

adds gitui to rust apps

view details

Kevin K

commit sha a11182c54e9460306d11000e3fe8c2bde3a45d21

fixes some alignment and defaults

view details

push time in 2 months

startedmatheuslessarodrigues/verco

started time in 2 months

issue commentclap-rs/clap

failure to parse invalid Unicode on Windows in v2.33.0 (but not master)

I think this was fixed in master because of the recent refactor done on OsStr by @dylni. It was a pretty big change (IMO).

Yeah that's why I referenced the other PR (part of the refactor). I haven't had time the last day or so, but I'll look at this new PR by this weekend and see if it's something that could go on the 2.x branch with the understanding that if v2-master is currently broken, so long as we don't break more we're in a slightly better spot even if its not a total fix.

Once v3 is fully released I fully intend to EOL v2 except for hard security patches

oconnor663

comment created time in 2 months

issue commentclap-rs/clap

Implement and Derive common traits

With #1365 we should look at how much this increases the binary size and probably feature gate this (it's ok if it's in the default features) if it negatively effects the size. I think LLVM is pretty good about dead code elimination and removing any trait impls that we impl (or derive) but aren't actually used in the resulting binary...but I'm not 100% certain in all cases. I know there are specific cases where LLVM won't remove dead code, but I believe that is tied to generics and monomorphic trait impls IIRC.

kbknapp

comment created time in 2 months

issue commentclap-rs/clap

Better looking visible aliases for subcommands

The difference between the two versions is aesthetic only and not structural, so I'd prefer to have one way to display it and stick to that. I don't think it's worth the overhead to provide an option to switch between whichever way is the default and the other way.

The same could be argued for options/flags, however the average long flag (and especially options) take up far more room than subcommand names, hence placing them at the back of the help message where they can easily be wrapped if required without throwing off the aligned of all other options/flags. Of course this doesn't apply as much to multi-line help messages (long_help), but those aren't the default.

The only aesthetic AppSetting we have is similar to this proposal is UnifiedHelpMessage, but I'd argue that's a whole different category and provides a common format used by a lot of CLIs.

As for which version I prefer? I don't have super strong feelings about either. I could be convinced that the new way looks a little better. But it also suffers from the alignment issue described above. Since this change only affects subcommands, I'd be fine accepting it. My only other concern is then the request to do the same for flags/options would become a request which I would be more against for the alignment issues.

Maybe it'd be worth a look through github and grep.app to see average length of subcommands/aliases because when combined with #1891if we lowered the default term width to 100, I'd want to make sure we didn't end up with help messages like this (exaggerated just for example):

    build, b            build your
                        site
    serve, server, s    serve you
                        site
                        locally
sondr3

comment created time in 2 months

issue commentclap-rs/clap

failure to parse invalid Unicode on Windows in v2.33.0 (but not master)

There shouldn't be many places where OsStr is assumed valid Unicode. Also see the potentially relevant PR #1893 the underlying code is different since its on the 3.x master branch, but deals with OsStr::starts_with

oconnor663

comment created time in 2 months

issue commentRustSec/advisory-db

Whitelisting non-vulnerable usages / false positives in advisories

Much appreciated! Just off the top of my head, maybe you'd probably want unaffected consumers to require a full version spec? In case the consumer has an update and starts using the vulnerability for real. It's more work to have to update the table to the new version being consumed, but ultimately its for the right reason to keep false negatives away which IMO are worse than false positives.

tarcieri

comment created time in 2 months

pull request commentclap-rs/clap

respect NoAutoHelp in _create_help_and_version

I also agree with @pksunkara's comments about making the settings more consistent :+1:

pmarks

comment created time in 2 months

pull request commentclap-rs/clap

respect NoAutoHelp in _create_help_and_version

Looks good to me, if someone else wants to give a second set of eyes as well just to make sure I'd appreciate it.

pmarks

comment created time in 2 months

issue commentclap-rs/clap

using a vulnerable rust-yaml version in clap v2

Just throwing my thoughts in the ring as well. I 100% agree with @CreepySkeleton here, there isn't much we can do unless yaml_rust backports the fix into a 0.3.x branch linked above. I think the clap team has put in a lot of effort here, as a clap maintainer has backported the fix to yaml_rust and opened the PR. Realistically the only thing we can do next is wait for the PR to be merged, or make a breaking change in clap. If this were an active vulnerability, I would be willing to make a breaking change in clap, but this isn't.

Having said that, I also agree with the sentiment that it's difficult for users to go through the headache of finding out what deps are causing which errors, and whether or not it's a real vulnerability. However, I would caveat that with that's just part of dependency management. Without better tooling, that's just the state of things.

The only other solution I can think of at the moment is if we add a blurb in our docs for the affected API that says something to the effect of, "There is a known false positive when using cargo-audit, link to discussion, use this cargo-audit config to ignore the error."

Licenser

comment created time in 2 months

issue commentclap-rs/clap

failure to parse invalid Unicode on Windows in v2.33.0 (but not master)

@oconnor663

We appreciate the very detailed bug report!

@pksunkara is correct, 2.x is currently frozen except security fixes. However, I'm willing to take a look at a PR to fix the issue, since I'm familiar with the codebase. I can't promise a merge if it looks to be too high a maintenance burden. Lets at least see how far reaching the fix is, since causing a crash on valid input could be considered a security issue if we wend the optics a bit to include remote binaries with DDoS potential.

oconnor663

comment created time in 2 months

issue commentclap-rs/clap

Alias short arguments

Does that mean we need to rename alias to long_alias and other methods similarly?

I hadn't thought that far yet.... ugh. :worried:

... [ thinking intensifies ] ...

I'd say no. So long as the docs are explicit that alias is for longs, and if they wish to find something similar but for shorts, look for short_alias I think it's fine.

connorskees

comment created time in 2 months

issue commentclap-rs/clap

Type no longer available for shells

@pksunkara I like the re-write, but I also think it'd nice to add a shell enum that dispatches the proper completion type. I haven't dug into it too deep yet, so it's hard for me to say if it should only include the currently supported shells, or all completion types...

Alternatively, we could so something as simple as provide an example, or clearly in the docs show how to create this enum and dispatch to the corresponding type. I agree it's pretty simple task, but to ease the transition from 2.x/structopt to 3.x, it'd help with this use case.

This is especially useful for the CLIs that provide the completion script generation at runtime via some CLI option (a la rustup with rustup completions <shell>).

alerque

comment created time in 2 months

issue commentclap-rs/clap

add {before/after}_help_{short/long} to App struct

I think this would be implemented as {after,before}_help_long and allow the current {before,after}_help serve as the short so that we don't have redundant APIs. This also would go along with the short somewhat being the default in clap as with all other settings that where both a long and short co-exist.

jeffka11

comment created time in 2 months

pull request commentclap-rs/clap

Add update_from_arg_matches to FromArgMatches

I haven't done a deep dive yet, but it looks like you're going down the correct path :wink:

Also, bikeshed we can probably call this method update as it's part of the FromArgMatches trait. I'm open to opinions. update_from_arg_matches isn't inherently wrong, just a mouthful that isn't semantically more meaningful than just update IMO. I'd like to hear other maintainers opinions though prior to making any changes so @lu-zero isn't just chasing rabbits for me haha

lu-zero

comment created time in 2 months

issue commentclap-rs/clap

generate_to ignores given argument and derives its own

I'm trying to remember exactly, but I think the reason I originally had the user pass in the binary name was because the App's bin_name doesn't get determined until runtime, however many shell completion script generations happen in a build.rs at compile time. So we need a way to tell the generating code what the binary would be called.

Of course this can be fixed by making App::bin_name or App::set_bin_name mandatory (side note we should fix the naming of those methods so they're less confusing. I know they one is &self and returns Sefl while other is just &mut self...I think the Rust idiom here is to make the &mut self's method name end in _mut...but I digress). But that should be well documented, or this invariant should be checked inside genereate_* methods via assert!s.

alerque

comment created time in 2 months

push eventkbknapp/rush

Kevin K

commit sha 4c27ecff0de963f980d1137678b8c99db7a6efed

removes vendored deps

view details

Kevin K

commit sha 70679360dc5abcec6768bdb37eddaced862a7b43

fix clippy lints

view details

Kevin K

commit sha 254b7090ba8b48823d58b926ecbedf84ef5c1301

removes nix files

view details

Kevin K

commit sha bee7baec2759be38ec746d6257325c5f7bc91afd

updates gitignore

view details

Kevin K

commit sha 9f62994735647ede886df095ac447ea80e499c1d

rustfmt run

view details

Kevin K

commit sha 8148695224cd18ec61221baf250b218ecd65ec4c

panic! -> assert! Allows rustc to make assumptions about the code and potentially make additional optimizations

view details

Kevin K

commit sha ac6dfdb27f19ba1dd68dfc39993225dcda9bba84

panic! -> unimplemented! It's more clear intent

view details

Kevin K

commit sha 7343a5d255e58c19b4ca3628d461aea7e07b54ab

wip: go from static mut to struct This will allow more idomatic rust, allows the borrow checker to enforce certain invariants, and removes large swaths of unsafe code. Now technically these bits of unsafe aren't necessarily unsafe, but it still helps clean up the code for *actual* unsafe review. One current struggle is `Packet`s want to be able to add statistics about how much memory has been freed, which before requires just mutating a static global. However, if the `Engine` becomes a struct, there is no way for a packet to have access to the engine. This will take a little refactor to create some kind of allocator. Also un-implemented as of yet is that `Engine` is not a singleton. This is an easy fix, it's just not yet done.

view details

push time in 2 months

fork kbknapp/rush

Rush: Snabb written in Rust

fork in 2 months

created tagclap-rs/term_size-rs

tagv1.0.0-beta.2

Functions for determining terminal sizes in Rust

created time in 2 months

release clap-rs/term_size-rs

v1.0.0-beta.2

released time in 2 months

push eventclap-rs/term_size-rs

Kevin K

commit sha e714b6a83f988b784ba4240c892a0edb2d0a5ae2

chore: increase version

view details

push time in 2 months

push eventclap-rs/term_size-rs

Ryo Yamashita

commit sha 7fd9eb280e8b4e93b572aef9190e30fb27213e09

WIP: Implement `dimensions_std[in|err]

view details

Cameron Martens

commit sha 6b369ce896203fd8761e0e22bda43629ff459c35

Fully implement dimensions functions on Windows

view details

Kevin K

commit sha 7361c69e99fd0d341823c65e4658812d3b604c29

Merge pull request #30 from camerondm9/implement-dimensions-stdin-and-dimensions-stderr Fully implement dimensions functions on Windows

view details

push time in 2 months

PR merged clap-rs/term_size-rs

Fully implement dimensions functions on Windows

This adds support for getting dimensions from stdin and stderr, as well as searching all 3 streams for dimensions (feature parity with the unix implementation).

+115 -44

3 comments

1 changed file

camerondm9

pr closed time in 2 months

issue commentclap-rs/clap

Alias short arguments

I agree it's a gap in what we currently offer. I can't say it'll make the cut for the 3.0 release, but it should be added shortly after.

Thanks for issue.

connorskees

comment created time in 2 months

pull request commentclap-rs/clap

Update README for beta release

bors r-

@pksunkara I should have asked, are you good, or do you have more to add?

pksunkara

comment created time in 2 months

pull request commentclap-rs/clap

Update README for beta release

bors r+

pksunkara

comment created time in 2 months

issue commentclap-rs/clap

Binary size could be smaller

A lot to reply to here :) I don't think we need to be concerned with embedded (bare metal) right now. Maybe one day, but there are many things we can do that will improve clap before we worry about embedded.

I'm more concerned with embedded like, i.e. resource constrained devices, like small arm based (Pi, SBC, phone, etc.). I spoke with some Google employees who were looking at clap for that exact use case (presumably Fuschia), and binary size was their concern. Binary size isn't everyone's concern. To be clear, I'm not trying to supplant argh, but I do think we should be cognizant of that use case while building clap.

We're in a little bit of a catch-22 scenario. Many people assume argument parsing is such simple task that the deps should be ultra small and no transitive deps. That's understandable why one would think that. However, as all of us know, it turns out argument parsing is somewhat of a hidden beast. There are edge cases EVERYWHERE, and a near endless amount of features to implement.

It turns out argument parsing is complex.

Having said that, the issue we're discussing conflates a few concerns that we should probably be more explicit about:

  • Binary size of clap
  • Compile times of clap
  • Adoption and Perception of clap

Both binary size and compile times are affected by:

  • Deps
  • clap features and code structure
  • Rust and LLVM compile time features (LTO, dead code elimination, monomorphization, etc.)

While adoption and perception can be heavily influenced by binary size, compile times, and the dep graph as it's own construct.

So long as we're doing our due diligence when it comes to crates we take on as dependencies to ensure they're worth the price we pay in terms of binary size and compile times, we're good. Alternatively, if they negatively affect those areas, we should do our best to ensure they're optional.

Meanwhile, we should be thinking about the dep graph as it's own construct because right, wrong, or indifferent people do care about how many crates they pull in. Unfortunately, everyone's reason for caring can be different, for some it's binary size, for some it's compile times, for others it's the perception of risk (what happens if a crates has a security flaw, or goes away over night?).

We're addressing the first two concerns already, but the third (perception of risk) is primarily addressed by either using ultra popular, well supported crates, or crates related to/owned by the parent (which is usually signalled by the name, i.e. clap_* for us).


"how would we sell clap to those guys" and I'm pretty sure the answer is - we wouldn't.

You're correct in that part of the answer is, "we don't." But I think we mean different things by this. I mean we "We don't try to sell them on clap, we just do the best we can to care about that scenario."

We can do things like making clap modular enough, or structured in a way to turn off features the end user doesn't care about. This has an added benefit of potentially being able to make most of our deps optional.

And where they can't be option, oh well. At least we're trying. clap isn't going to fit every situation and that's fine. But we should at least do what we can to be an option for even those resource constrained situations.


If their wariness comes from concern that the deps affect binary size, we can righteously tell them that all the deps put together (in --no-default-features mode) take less than 5KiB, the next rustc release will likely change much more of that. The same can be said about compilation time: ~2sec difference, essentially a rounding error.

I totally agree with you. However, the problem is many times we don't get the chance to explain ourselves. They see the dep graph front-and-center and many times simply make assumptions from there. That's the part about the "no dep" crowd I'm not a fan of. I can't count the number of reddit comments, or blog posts I've seen that say, "Can you believe [program X] pulled in 170 crates?! That's absurd!!!" with no backing evidence as to why that's absurd. Were those 170 crates not required? How much compile time did they add, etc.? If the compile times were the EXACT same, but [program X] just copy/pasted the code from those crates, you probably wouldn't hear a peep. In fact, you'd probably hear how amazing it was that [program X] has no dependencies!

...I'm not a fan of that. But it's the world we live in.


What not clear to me is your logic about "either pulling the code internal, or dropping the crate". It sounds like "Let's copy-paste code from third party crates (we can't just drop them) in order to decrease our maintenance burden"

I should have been more clear :stuck_out_tongue_winking_eye: Decreasing our maint burden and decreasing our dep graph are separate concerns that get intertwined. Also taking the code internal is only in the case where we're using a dep for a small well defined subset of what the crate offers, and we aren't concerned with maint burden part, just the raw number of deps part. This should only be a last resort for us.

This is one of those things that's counter intuitive; copying and pasting a subset of a crate into clap directly, (or even into a new sub crate like clap_foo may actually not make any difference in compile times or binary size. But it will still make many people "feel" better about using clap.

Is it dumb. Yep. But again, this should be a last resort for us and not something I'm actually looking at doing seriously. The only crate that comes to mind for this type of thing is term_size which is technically already a clap owned crate, but again the name doesn't signal that so when people compile clap they just assume it's some rando crate we pulled in as a dep. Am I suggesting re-naming term_size to clap_foo? Nope. Not unless we were in drastic territory and have exhausted all other options. We're nowhere near that! :smile:

smklein

comment created time in 2 months

more