Skip to content
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

Should structopt re-export paw? #407

Closed
epage opened this issue Jul 9, 2020 · 4 comments · Fixed by #413
Closed

Should structopt re-export paw? #407

epage opened this issue Jul 9, 2020 · 4 comments · Fixed by #413

Comments

@epage
Copy link
Contributor

epage commented Jul 9, 2020

clap-verbosity-flag is a crate that provides a reusable set of arguments. When someone tried to use clap-verbosity-flag with paw, it broke:

error[E0433]: failed to resolve: use of undeclared type or module `paw`
  --> /Users/edpage/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-verbosity-flag-0.3.1/src/lib.rs:21:10
   |
21 | #[derive(structopt::StructOpt, Debug, Clone)]
   |          ^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `paw`

error: aborting due to previous error

structopt has the paw feature on but the symbol paw isn't visible within clap-verbosity-flag to be able to compile.

Currently structopt re-exports clap. Should it also re-export paw?

@CreepySkeleton
Copy link
Collaborator

CreepySkeleton commented Jul 10, 2020

I say we can gate the reexport under cfg(feature = "paw"). Will that suffice? (I didn't read the linked issue, sorry)

@CreepySkeleton
Copy link
Collaborator

CreepySkeleton commented Jul 10, 2020

Wait, we can't reexport it because, astonishingly, structopt doesn't depend on in 😮 We just generate some extra code when the paw feature is enabled, and that's about it :)

On the other hand, if the end user of your crate enabled the feature, they depend on paw already, and we can depend on it without extra trouble.

@TeXitoi what do you think about it?

@CreepySkeleton
Copy link
Collaborator

Fat chance.

Caused by:
  Features and dependencies cannot have the same name: `paw`

We can't depend on paw because we have a feature named paw, so paw is off-limits dependency for us. We can't rename the feature because it's API contract. We can't just get rid of the feature and rely on the implicit feature the paw dependency would introduce because implicit features cannot enable other features (we need it to enable structopt_derive/paw). If we can't depend on it, we can't reexport it. If we can't reexport it... You get the idea.

I'm afraid this is just unsolvable with no hope on horizon, so I think the only solution is to avoid using the feature. IMHO, it doesn't have any value except giving you warm nostalgic feelings from good old C days when you got the args passed directly to main.

@CreepySkeleton
Copy link
Collaborator

I did it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants