I have a project using Rust nightly with logos 0.11.4 as a dependency. When I run cargo build, I get
error: failed to download `logos v0.11.4`
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at `C:\Users\jonat\.cargo\registry\src\github.com-1ecc6299db9ec823\logos-0.11.4\Cargo.toml`
Caused by:
readme file with name '../README.md' was not found
It turns out that logos has a nested package called logos-derive, and the Cargo.toml for this project has the line readme = "../README.md". In other words, it's pointing to the README from the parent directory. However, the Cargo source registry places the logos-0-11.4 and logos-derive-0.11.5 directories at the same level, rather than nesting them, which explains why the file is not found. I can actually get it to build by creating an empty .cargo/registry/src/github.com-1ecc6299db9ec823/README.md. But that's obviously not a satisfactory long-term fix.
Note that I was able to build just fine two days ago (2020-06-11), but despite there not being any changes to logos or logos-derive in that time, I'm now unable to build - even after checking out my project from that time and downgrading my toolchain to nightly-2020-06-11. I'm not sure how that's possible or what in my build process has changed.
Am I doing something wrong, is logos-derive doing something wrong, or has Cargo changed something recently? Anyone have a proper solution?
The issue seems to have mysteriously disappeared again in nightly-2020-06-13. I don't know what the cause was, but I guess this is resolved.
Related
For some reason Rust Analyzer isn't generating a warning for undefined variables. Do I need to tweak some settings somewhere?
I'm also not getting warnings for unused variables, unimported crates, etc.
Edit: Tested this out with a new workspace. Both cargo check and Rust Analyzer work. It reports a single intentional error. When I run cargo check in the first workspace, it reports a lot of errors in the ~/.cargo directory, and none in the current workspace. Perhaps a crate I am using has errors and is locking up cargo check before it can get around to checking the files in my directory?
The log when running cargo check showed some issues with ~/.cargo/registry/src/github.com-xx..xx/rppal-0.12.0. This came from a the crate rust_gpiozero that I had listed as a dependency. As best as I can figure, cargo check was failing on this and then ceasing to analyze my files. After removing this dependency, both cargo check and Rust Analyzer run as expected.
Cheers to all who replied to this thread for their guidance.
Rust-analyzer itself doesn't produce errors or warnings for this.
If you want warnings and errors, enable the "Check on Enable" option in the rust-analyzer extension. This will run cargo check every time you save a Rust file and display the emitted warnings and errors in the files.
For another possible cause: try cargo clean.
This problem happened to me after upgrading my toolchain version. As mentioned in other answers, running cargo check yielded many errors. The topmost error mentioned a crate "compiled by an incompatible version of rustc." Running cargo clean followed by cargo check fixed all errors.
Have a Jenkins Pipeline that downloads a testing repo from bitbucket then does the following:
gradle build --refresh-dependencies
One of the dependencies is as follows:
compile 'org.codehaus.groovy:groovy-all:2.5.5'
We have the Pipeline running every 30min, and at least 3-4 times a day a build will fail with the following error:
Could not determine artifacts for org.codehaus.groovy:groovy-all:2.5.5
> Could not get resource '<pathToResource>/org/codehaus/groovy/groovy-all/2.5.5/grovy-all-2.5.5.jar'.
> Could not HEAD '<pathToResource>/org/codehaus/groovy/groovy-all/2.5.5/grovy-all-2.5.5.jar'.
> Read timed out
I've tried upgrading the version of groovy-all, as well as specifying the ext/type as pom. When specifying the type I get a new error as follows:
> Cannot infer Groovy class path because no Groovy Jar was found on class path:
As I said this only happens about 3-4 times a day, out of 48 builds a day, so it's very inconsistent and happens at random intervals.
We can't revert groovy-all to a previous version where the .jar exists, so is there any solution to resolve this?
You say the problem is intermittent so it sounds like you are timing out when downloading the artefact. Are you caching it locally (Artifactory, Nexus or similar)? If not, look into doing so. If you are caching locally, I'd check if something is flushing the cache
I am studying an aplication that has some dependencies. I want to make some changes on one dependency locally.
I tryed to make a symbolic link inside the main application's node_modules direct to the dependency folder, where I have the folders with compiled code (es and lib) using this command ln -s dependency_folder main_app/node_modules/dependecy.
It doesn't work and raises an error:
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/warnings/invalid-hook-call-warning.html for tips about how to debug and fix this problem.
Is this a right way to develop a dependency package, or I am doing it wrong.
I realize that there is no problem to link to a dependency package. What happened here is that the project source files are out of date. Compiled dependencies are up to date on NPM, on git the sources are outdated.
i will leave this message just for the records.
This is a weird question. I'm converting an existing site to Gatsby (a Node package I installed with npm i -g gatsby-cli), and when I run gatsby develop I get an error:
Error: ENOENT: no such file or directory, stat '/home/me/.steampath'
Now the backstory here is that on Linux Steam deliberately installs a bad symbolic link called .steampath for some stupid reason. But what I can't understand is why/how running a specific Node application (Gatsby) could result in this error, which has nothing to do with my project or Gatsby ... when running other Node apps doesn't.
I've done a grep through my project directory: steam doesn't appear in any file. Similarly I grepped my environment (env | grep steam), and there's no environmental variable pointing to that file.
So can anyone answer: why does running Gatsby cause an error in a completely unrelated symbolic link sitting outside the project in my home folder?
I imagine Gatsby must be running some sort of system command, but I can't even imagine what it could run that would scan my home directory and complain about broken symbolic links.
P.S. This error comes at the end, after other errors, so it doesn't look like it's causing gatsby develop to fail so much as it's reporting the error at the end.
P.P.S. Removing the bad symlink does fix things (although I don't know what Steam will think) ... but then I get another error about another broken symlink in my home folder (I can't blame Steam for that one). So something Node/Gatsby is doing is resulting in a scan of my home dir, and a complaint about any broken symlinks found!
Once all broken symlinks are removed Gatsby works normally. So bizarre!
An answer to your question can be found here
I also had this issue today, it surfaced when one of my JS imports was
not installed (redux). Adding the dependency fixed the issue. When the
dependency was absent from the node_modules directory, something (i
didn't dig far enough) would stat my entire home directory. With the
dependency present the ~ directory was left alone.
It's related to the node resolution algorithm and although more information is not given, I believe it may be related to this
I was also quite worried when I initially saw this error.
I'm attempting to compile a kivy app for android using the python3crystax recipe. When building only with recipes listed in python-for-android, it compiles fine, but whenever I attempt to add a pip dependency, it fails with this error:
[ERROR]: Didn't find any valid dependency graphs.
[ERROR]: This means that some of your requirements pull in conflicting dependencies.
[ERROR]: Exiting.
When using the python2 recipe, however, it compiles fine. Does python3crystax support installing dependencies over pip?
It sounds like your dependency does have a recipe, but that the recipe isn't marked as python3crystax compatible. Give more information about what you're attempting if you want a more specific answer.
I was able to workaround this issue by changing the python-for-android branch that buildozer uses from stable to master in my buildozer.spec file. This gave me access to the new python3 recipe and that seems to be working fine.