Closed dvtomas closed 1 year ago
Hello, anybody has an opinion on this?
Makes sense to me. structopt
and meval
is only used in the binary CLI so I think it might be able to be moved to [dev-dependencies]
. should be easy
ah sorry, no it can't, but yeah it could be split into a feature and the CLI bin could be set to require that feature.
There's a discussion on how to do that in the "useful links" mentioned above.
/cc @micouy
Any thoughts on this yet? IMHO it would be the best and easiest to just make the CLI another example. I'm willing to do a PR if you agree.
??
I agree, I just hit this myself causing a duplicate dependency of a different version when I'm just using it as a library. I lean slightly towards the optional dependency or separate crate fix myself though.
yep, would be great to have those options. Unfortunately, the crate becomes unusable in some cases. Allowing those things to be optionally enabled as features or as separate dependency would solve the issue.
meval
seems to be unmaintained, and it depends on nom = ^1.0.0
, which will become rejected in a future version of rust (https://github.com/rust-lang/rust/issues/79813). The possible fixes for this upcoming deprecation are:
nom
to a 1.x.x
version (https://github.com/rust-bakery/nom/pull/1657). The fix is currently only live on versions ^5.1.3 || ^6.2.2 || >=7.0.0
meval
to merge https://github.com/rekka/meval-rs/pull/27meval
or fork itI think this should go into another issue.
Anyway, If looking for an alternative, I've had a good experience with evalexpr
Fixed in #40
I'm using textplots as a lightweight lib only. Would it be possible to either split it into two crates, or use features, to have a
structopt
andmeval
dependencies free build?