-
Notifications
You must be signed in to change notification settings - Fork 29
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
Travis: Some components might not cargo test
because dependencies are too recent
#468
Comments
I don't have any other idea so far... I hoped that the |
I think we actually need to use "=" for those dependencies that are problematic (eg: serde), but not all of them. About clippy that's also problematic, maybe we should have it in a feature and make it optional. |
using What's the problem with clippy? |
Same problem than serde: it breaks every then and now when it is updated for a newer rust but our rust is not (for example). I know the issue that comes from "=" but I don't have better options right now. If we keep it for the 1 or 2 problematic dependencies this is likely manageable. We can also use ">= XXX < YYY" and update YYY when we try it and see it still builds. But this is a lot of work I'm not sure we want to tackle. |
Spotted in this job and that one. That's also reproducible locally.
STR
cd components/taxonomy
cargo test
Results
aster 0.16.0
can't compile because it's meant to be built against a rustc more recent thannightly-2016-04-10.
Short term solution
#465 will rust up, so the problem will go away, until next time.
Root causes
This problem is due to the accumulation of these causes:
cargo test
doesn't the tests of components (like described in Components tests are not run withcargo test
at the root of foxbox #449).^
is implied when defining version of dependencies (e.g.:serde = "0.7.0"
is equivalent toserde = "^0.7.0"
and notserde = "= 0.7.0"
)Long term solutions?
=
for every dependency in Cargo.toml"). I tried it locally, and I still didn't manage to compile taxonomy.taxonomy
is out on crates.io. People might face the same type of compiling error, without us knowing. They'll also have to freeze their Cargo.lock to comply with the one we have.None of them seems actionable in a short term perspective. @fabricedesre @julienw do you see something else that we could do?
The text was updated successfully, but these errors were encountered: