This might be a rather general question: How to deal with incompatible packages in meteor?
In my case I'm using the testing suite velocity and jasmine, which is not compatible with the current version of autoform-file package.
My html-reporter would just continue executing the test without actually getting the result due to the following error:
Errors prevented startup:
While selecting package versions:
error: Potentially incompatible change required to top-level dependency: yogiben:autoform-file 0.3.0, was 0.4.2.
Constraints on package "yogiben:autoform-file":
To allow potentially incompatible changes to top-level dependencies, you must pass --allow-incompatible-update on the command line.
Your application has errors. Waiting for file change.
I was thinking of downgrading the autoform-file package to 0.3.0 however, I didn't find any information on how to do it.
I was able to install the package at a specific version using:
meteor add yogiben:autoform-file#=0.3.0
That worked for me.
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 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).
I am using pacman to install and load the mentioned libraries. But it is throwing a dependency error and lock error in installing caret.
My main motive to use this library was to auto detect the libraries in R so that if present, load the library else install and load.
pacman::p_load(dplyr,caret,plyr) was the code that I used.
install.packages("Rcpp", dependencies = TRUE, INSTALL_opts = '--no-lock')
In place of Rcpp you can pass a variable which will change according to your iterations for every record on the list having the names of libraries to be downloaded.
It solved my issue.
The dependency error may be due to pacman::p_load() default behaviour being not to update packages that already exist in your r library.
Thus, if in this example, you are trying to install caret (which you don't have in your library) and it has a dependency Rcpp (which is already in your library because it is also a dependency for several other packages that you have already installed, or you installed it separately previously), pacman::p_load() will install caret and not update Rcpp.
This may then generate a conflict if the latest version of caret also depends on the latest version of Rcpp, but you have an old version of Rcpp.
Instead, you can change the update argument to TRUE:
# Check for, install (if necessary) and load packages:
pacman::p_load(dplyr, caret, plyr, update = TRUE)
This may not be a sufficiently targeted solution, because it will update the desired packages AND their dependencies, whereas ideally it would be better if only dependencies that failed to meet the minimum required version number for the desired packages are updated.
I am trying to use Travis CI with an R package (specifically this in-development package here).
When I update a repository, I get the following message (see the logs here):
Error: processing vignette 'comparing-mclust-and-mplus-output.Rmd' failed with diagnostics:
'roxygen2' >= 5.0.0 must be installed for this functionality.
Execution halted
This is consistent across two different packages--although the version of roxygen2 that I have is 6.0.1. I haven't been able to find others with this particular issue on either Stack Overflow or the roxygen2 GitHub page. I used usethis::use_travis() to set up the package for use with Travis (i.e., add travis.yml file.
Any ideas about how to address this?
So I believe the problem you have is with your DESCRIPTION file. Travis will install all package dependencies before trying to build the package / vignettes, so the version you have installed locally is of no consequence.
Rather, you need to be sure that roxygen2 is a dependency of your package (probably only needed in Suggests if it is necessary to build but not use your package). So adding:
Suggests:
roxygen2
To your DESCRIPTION file should fix the issue!
I just updated my meteor application to meteor version 0.9.0
All seems to work well. The problem however now is that when I do a fresh checkout of my project and try to run it I get errors like this:
% meteor
Figuring out the best package versions to use. This may take a moment.
Could not resolve the specified constraints for this project:
Error: unknown package: subs-manager
So I tried to install the packages as follows:
% meteor add subs-manager
Figuring out the best package versions to use. This may take a moment.
Could not resolve the specified constraints for this project:
Error: unknown package: subs-manager
and next I tried:
% mrt install subs-manager
Done installing smart packages
But when I try to run meteor again I get the exact same error message. Any suggestions what goes wrong here ?
You need to migrate your package names:
meteor remove subs-manager
meteor add meteorhacks:subs-manager
You can check out the names by searching atmosphere, which I think uses the new naming system now or using meteor search e.g meteor search subsmanager