I had used Julia some months back for a project, and didn't use it since. I hadn't faced problems back then. But now, I absolutely am not able to install any package.
(#v1.5) pkg> add Distributions
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package Distributions [31c24e10]:
Distributions [31c24e10] log:
├─Distributions [31c24e10] has no known versions!
└─restricted to versions * by an explicit requirement — no versions left
Any package I install, I am getting the same error. How do I fix it?
This is the status of Pkg:
(#v1.5) pkg> status
Status `C:\Users\jaine\.julia\environments\v1.5\Project.toml`
[6e4b80f9] BenchmarkTools v0.5.0
[7073ff75] IJulia v1.21.2
[91a5bcdd] Plots v1.6.0
[438e738f] PyCall v1.91.4
[d330b81b] PyPlot v2.9.0
[2913bbd2] StatsBase v0.33.0
Given
├─Distributions [31c24e10] has no known versions!
it looks like you have a missing or corrupt package registry. The package manager will reinstall it for you if you delete .julia/registries and try to add the package again.
You can do this from within julia
rm(joinpath(homedir(), ".julia", "registries"), recursive=true, force=true)
These are indeed some of the more tricky situations to resolve so please bear with me as we work through this.
If you are not familiar with the basics of the package manager, it's worth a quick read to check out: https://julialang.github.io/Pkg.jl/v1/getting-started/
Assuming you are now in the Julia Repl, my general work flow for these issues is to remove everything it warns me about. The core problem here is that one of your existing packages is saying it needs a specific version of Distributions.jl but it's not able to add it. So, the first step would be to enter the pkg manager by doing ] and type rm Distributions.
Then, while still in the pkg mode, do resolve and add Distributions.
So the process is to just remove each package the Repl complains about until it stops complaining.
Note: If you run into something like this again, the worst-case scenario is to remove the project and manifest files for the specific Julia version you are using. If you navigate to ".julia/environments" you should be able to completely reset the Julia Env for a specific version there (that way you don't need to actually reinstall Julia).
Related
I am trying to use the Twitter.jl package locally on my M1 Mac. However, when I try to install it, I get:
ERROR: Error building `DecFP`:
┌ Warning: Platform `arm64-apple-darwin21.2.0` is not an officially supported platform
└ # BinaryProvider ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:450
ERROR: LoadError: KeyError: key "unknown" not found
DecFP looks like it's an up to date Julia package so I am not sure what the issue would be in this case.
I would like to get a general set of steps to resolve issues like this since I know this package isn't the only one that will have installation issues so hopefully this can be used to help others who have similar issues.
The issue is that Twitter.jl is pulling an old version of OAuth.jl which doesn't work on the M1. I have opened a PR so it pulls a newer version and it should work.
About these cases in general the steps are identifying what package is using BinaryProvider, in this case it's an old MbedTLS that was pulled by an old OAuth. The solutions are, if there is a newer version, change the compat bounds, and if there isn't then one has to build the needed binary using BinaryBuilder.jl and change the dependent packages to use it.
In most cases just opening an issue in github should be enough :).
I keep trying to add IJulia in the REPL, and I keep getting this error message:
I tried installing JSON directly, but the REPL would say "The following packages names could not be resolved".
If it helps, I'm running a Windows 10 laptop with julia 1.0.5
Is there a fix to this? Should I install an earlier version to julia?
Appreciate the time.
It seems like you have outdated registries locally.
The registries are ~/.julia/registries, message like The following package names could not be resolved usually suggests that registry are not updated or somehow corrupted.
Delete them (the directory ~/.julia/registries/General) and then adding packages should cause the General registry to be downloaded, the newest version. Then you should be able to add IJulia without problem.
More people encountered this problem with messed up registry, see https://discourse.julialang.org/t/registry-failed-to-update/17840/10
I´m developing an R package in RStudio and a set a local library to contain all my packages. After installing some updates in my Ubuntu system, it seems that my R Project have lost track of the local library and is unable to load the libraries that were associated with it. If I try to Build & Reload the package with
R CMD INSTALL --no-multiarch --with-keep.source mypackage
The program tries to install to library '/usr/local/lib/R/site-library/' which is rejected with:
ERROR: No permission to install to directory '/usr/local/lib/R/site-library/'
As far as I remember, whenever I rebuilt my package, that line pointed to my local directory, where all my libraries were localted
installing to library ‘/home/user/R/x86_64-pc-linux-gnu-library/3.2’
It is clear that somehow R have lost track of the connection between the project and the libraries.
I tried re-including the path with
.LibPaths("/home/user/R/x86_64-pc-linux-gnu-library/3.2")
but, just after I rebuild the package again, the program created a 3.3 directory in x86_64-pc-linux-gnu-library. From there, it is unable to find the libraries that are associated to my program and throws another error:
ERROR: dependencies '...', '...' are not available for package "mypackage"
Is there a way to restore the program to the way it was before so I don't have to reinstall everything and start from scratch?
By default, R adds the major-minor version numbers to the library path (?.libPaths) for a good reason, assuming that the jump from 3.2 to 3.3 introduced efficiencies or incompatibilities. It is implied that this version jump requires new installation of packages.
If you override this, packages assembled in 3.2 may not always play nicely in 3.3. (I'm not going to test this theory, please report back if you can disprove this statement, I'm honestly interested!)
BTW: your call to .libPaths seems suspect: I don't know of a capital-L version, and when calling it you should include the previous path (unless you truly mean to omit the system R library paths entirely), such as:
.libPaths("/home/user/R/x86_64-pc-linux-gnu-library/3.2", .libPaths())
If you choose to do that, any bugs you may find in others' packages are possibly due to that incompatibility and should not necessarily be reported to developers.
Another option would be to re-install all packages from your 3.2 installation into your 3.3 library path. Something like this should help automate the process:
# to reinstall packages installed in R-3.2 subdir into R-3.3
install.packages(list.files(path = "~/R/x86_64-pc-linux-gnu-library/3.2"))
I (finally) just installed ggplot2 by doing it from R directly and turning off antivirus. (It had previously failed out on moving the temp files for stringi and magrittr, so I followed the advice in StackOverflow.)
And it worked. But I have a few puzzles about its behaviour. The command I used was:
install.packages("ggplot2", repos = getOption("repos"), dependencies = TRUE)
Two things that happened as a result puzzled me:
it didn't ask me what repos I wanted to use - but just went to
imperial (which is fine with me)
it didn't install the dependencies - which I discovered when I did
library, so I installed the missing ones manually one by one (luckily
there were only two - the two that had failed out when I had tried an
install from RStudio with my antivirus on)
I have read the documentation on install.packages() but haven't understood it, as both these behaviours were different from what I expected. I thought I would get a query about what repos to go to, and I thought I would get the dependencies tagging along on the install.
Can someone explain?
Thanks.
It always install dependencies. That is the whole point of
having repos -- and why CRAN was so important over these 20 years, and
declaring dependencies in DESCRIPTION.
Now, I set my repos in the startup file (Rprofile.site in my case, see help(Startup) and its examples section for how). You can also just call options() before calling install.packages(). The dependencies=TRUE is also superfluous.
But thinks you need to check and did not tell us: source or binary installation? What OS? What is your R version and does it mesh with what the repos expect -- a current version on R?
My Fedora system (Fedora 20, all up to date) has just had R updated to version 3.1.0. Since then, I've had issues installing multiple packages. glmnet failed previously, and now I'm having trouble with treemap. More specifically, I get an error during treemap installation that httpuv has zero exit status.
I never had issues with the previous version of R. Any reason this version should have such problems??
There could be many causes to do with your OS, version, permissions, other installed packages/software, etc, etc. Without seeing the full error message it's hard to know.
One possibility specific to httpuv is root privileges. I've noticed a few threads on various forums when searching for installation errors with this package and Linux, many of them mentioning root v. non-root issues. In another case, libuv needed to be upgraded.
I encounter package installation problems daily and I have some more general work-arounds as well. Hopefully one of these will solve your problem.
Install the package from source
download.file(url="http://cran.r-project.org/src/contrib/httpuv_1.3.0.tar.gz", destfile = "httpuv.tar.gz")
install.packages("httpuv.tar.gz", type = "source", repos = NULL)
Install using devtools via GitHub if the package supports it
Install RTools and re-try your package installation
Install an older version of the package
If those above do not work, then I dig deeper by referring to advice given to me by a VP of IT in my company. These comments were made in reference to frequent package installation problems I encountered when switching from Windows to Solaris:
There are two types of install/make problems. Missing .h files
and/or missing .so/.a libs. The reason for these are multiple:
1.- the package that delivers these is not installed. This means that those files cannot be found anywhere in the /usr tree. Solution is
install right package, make sure the files are there
2.- the includes are not found by the install configurator. This means some environment variable or install option is not properly set (this
is our case for RODBC). Figuring out which variable to set is
challenging without looking at the package documentation [fortunately, documentation is not hard to find!]
3.- the libs are not in the LD_LIBRARY_PATH, easy to fix.
4.- There is a deeper compile/link error, meaning the package is not compatible with the rest of the sw, or has not been properly ported.