Doesn't compile with default-features = false
ArtemGr opened this issue · 7 comments
Hey!
When I build the latest version with "meval = {version = "*", default-features = false}" I get the following error:
error[E0432]: unresolved import `serde::de`
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/meval-0.0.8/src/de.rs:2:5
|
2 | use serde::de;
| ^^^^^^^^^ Maybe a missing `extern crate serde;`?
error[E0432]: unresolved import `serde::de::Error`
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/meval-0.0.8/src/de.rs:3:5
|
3 | use serde::de::Error;
| ^^^^^^^^^^^^^^^^ Maybe a missing `extern crate serde;`?
error[E0432]: unresolved import `serde::Deserialize`
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/meval-0.0.8/src/de.rs:4:5
|
4 | use serde::Deserialize;
| ^^^^^^^^^^^^^^^^^^ Maybe a missing `extern crate serde;`?
This is not supposed to happen, right?
Thank you for reporting! Sorry about that, I didn't test it properly... I will fix it as soon as possible.
By the way, I do not recommend using version = "*" at the current stage, the api has breaking changes at every new release, before I settle down on what I am happy with.
It should be now fixed in 0.0.9.
Sorry about that, I didn't test it properly... I will fix it as soon as possible.
Rest easy, it's not a big deal.
It should be now fixed in 0.0.9.
Thanks!
By the way, I do not recommend using version = "*" at the current stage, the api has breaking changes at every new release, before I settle down on what I am happy with.
Don't you need early testers or something?
Thing is, it's often much easier to track the small incremental changes with "*" than to attract a technical debt of using a version that is essentially "archived" and no longer being tested or maintained. With version = 123 it's easy to stay behind, missing the point when the project bit rots and gets old.
More than that, some crate changes might be poorly documented (i'd point a finger at capnp and serde) and I would've be at a loss trying to do an upgrade if I haven't, with version = *, caught it in time to see the relevant git commits. Finding these commits later is harder.
When I do a "cargo update" I usually have some time for the upgrades.
On the other hand, when something breaks from an old age, during a Rust upgrade for example (or, in the case of capnp, because of the upgrades in the underlying C/C++ library), there's usually a shortage of time and trying to fix multipe packages at once might bring considerable stress.
P.S. Yet another reason to keep your project at "*" is intersecring dependency sets. I use nom myself and I don't want the versions to diverge unnecessarily.
Don't you need early testers or something?
I appreciate early testing! But since I don't really know what I am doing and I'm developing this lib for my use in a numerical math project for an easy configuration, the api changes might be sudden and quite nonsensical. Suggestions are always welcome.
Thing is, it's often much easier to track the small incremental changes with "*" than to attract a technical debt of using a version that is essentially "archived" and no longer being tested or maintained. With version = 123 it's easy to stay behind, missing the point when the project bit rots and gets old.
You are right, with a binary crate it is not a problem since Cargo.lock is tracked in the repo by default, so one has to run cargo update manually to compile with a newer version. I still wouldn't recommend version = "*" if you are making a library though.
More than that, some crate changes might be poorly documented (i'd point a finger at capnp and serde) and I would've be at a loss trying to do an upgrade if I haven't, with version = *, caught it in time to see the relevant git commits. Finding these commits later is harder.
I have started keeping track of changes in CHANGELOG.md for exactly this reason.
P.S. Yet another reason to keep your project at "*" is intersecring dependency sets. I use nom myself and I don't want the versions to diverge unnecessarily.
Specifically in the case of nom, meval is using nom = "1.0.0", which should imply that it is compatible with any version >= 1.0.0 <2.0.0. So unless nom releases a new major version, there should be no issue with versions diverging.
I still wouldn't recommend version = "*" if you are making a library though.
Sure thing!
Specifically in the case of nom, meval is using nom = "1.0.0", which should imply that it is compatible with any version >= 1.0.0 <2.0.0. So unless nom releases a new major version, there should be no issue with versions diverging.
They have released nom 2. I've ported my code there and I wondered whether you're going to eventually upgrade as well. ; )
Basically it's a shift from chain! to a lighter do_parse!, as far as I've seen.
They have released nom 2. I've ported my code there and I wondered whether you're going to eventually upgrade as well. ; )
Oops. I haven't kept up with their development since I wrote the parser a long time ago. Thought that it'd be stable. :) Fortunately, nom 1.* is a very light crate with no dependencies itself, so I'm not too motivated to upgrade.
It is stable, but far from perfect, IMHO. I filed a bug or two. Also, I prefer to work on &str; rather than converting back and forth, and &str; support is still being tackled here and there. Eventually I hope nom will be better than it is now.