Mac64 R> install.packages("quantmod")
Yields a discouraging message. Namely,
Warning: unable to access index for repository http://www.ibiblio.org/pub/languages /R/CRAN/bin/macosx/leopard/contrib/2.12
Warning message:
In getDependencies(pkgs, dependencies, available, lib) :
package ‘quantmod’ is not available
No big deal, just pass in a different repo, like this:
Mac64 R> install.packages("quantmod", repo="http://R.research.att.com")
And all is well. But how do you set the default repo so you don't need to pass it in every time? In Ubuntu, there is a file that manages this but the documentation for Mac OS X is a bit sparse.
Can't tell if you are using the R64.app GUI but guessing that you may not be. You can set the default repository in the r/Preferences/ panels if you are using R64.app. Personally I use the repository at the same facility that hosts StatLib which shows up on some dialogs something like USA (PA 1) but on my Preferences pane is http://lib.stat.cmu.edu/R/CRAN . Here is a bit of ?options that may be of interest:
repos:
URLs of the repositories for use by update.packages. Defaults to
c(CRAN="#CRAN#"), a value that causes some utilities to prompt for
a CRAN mirror. To avoid this do set the CRAN mirror, by something
like local({r <- getOption("repos"); r["CRAN"] <- "http://my.local.cran";
options(repos=r)}).
Note that you can add more repositories (Bioconductor and Omegahat, notably)
using setRepositories().
At the moment my "other repository" setting in the the R64.app is http://www.stats.ox.ac.uk/pub/RWin/bin/macosx/leopard/contrib/2.12/ , because I was doing something to get a package that was only at Ripley's site but it is usually set to R--Forge: http://r-forge.r-project.org/
See the help for function setRepositories; you can manage your list of repositories in a GUI or by editing the file R_HOME/etc/repositories.
You can know what is your R_HOME directly in R:
> R.home()
[1] "/usr/lib/R"
http://cran.r-project.org/doc/manuals/R-admin.html#Managing-libraries
Try creating the folders and files as suggested for UNIX-like systems; chances are that R will check for them on OS X as well when looking for repo settings.
Related
This bounty has ended. Answers to this question are eligible for a +100 reputation bounty. Bounty grace period ends in 4 hours.
antonio wants to draw more attention to this question:
Explain what is the proper workflow when you are building two packages, where one depends on the other. What is the correct way to run devtools::check() on the depending-on package?
I want to add a local package dependency using R devtools.
The suggested way to add packages to the package DESCRIPTION file is one of the two functions use_package() and use_dev_package(), from the usethis package. The latter adds a dependency on an in-development package. The function help shows the following prototype:
use_dev_package(package, type = "Imports", remote = NULL)
where remote is
a character string to specify the remote, e.g. ‘"gitlab::jimhester/covr"’, using any syntax supported by the remotes package.
The remotes vignette shows the following
# Local
Remotes: local::/pkgs/testthat
So the command should be along these lines:
use_dev_package(foopack, type = "Imports", remote = "local::<foopack>")
However, what should be the path to the foopack. An absolute one or relative to project dir? The root package directory or the R directory with the code, or perhaps the foopack.tar.gz build?
All attempts failed for me.
Needless to say that, beyond having the local dependency properly listed in the DESCRIPTION file, I need it to be seen by the devtools build & check functions.
Edit
As regards use_dev_package(), I found a solution:
if I use devtools::check(), then the dependency appears in the search path, and use_dev_package() does not complain any more (see answer below).
However, it is still unclear to me what arguments should I use to make a development check() for the main package, in particular when the package has a vignette.
Ideally, I should be able to pass the check with local dependencies by passing cran = FALSE, but this still gives
"Package required but not available".
It seems that I have to check the local dependencies before adding them to the description file.
devtools::check("path/to/foopack")
usethis::use_dev_package("foopack", remote ="local::path/to/foopack")
The paths can be relative or absolute, and even a single colon works.
It might be worth noting that, when I build the main package, I can use the ordinary:
devtools::build()
but, for a successful check, I need to use the remote argument:
devtools::check(remote = TRUE)
I can't see a rationale for restating what is in the DESCRIPTION file, but I do not have enough expertise to say it's a bug.
Let's see what the others say in this regard.
Edit
Unfortunately, it seems that the remote argument above does not apply to vignettes. So, if I add a vignette to the package, checks fail with local packages
Until an actual solution is found, all I can do is (sadly) to ignore vignette checks:
devtools::check(remote = TRUE, vignettes = FALSE)
I have an RStudio project that manages packages using renv, which works great.
But sometimes I want to debug or explore something using libraries on my main environment(right word?) that I don't want to add to the project. For example, maybe I want to run some long debug function and call beepr::beep() at the end. Is that possible without installing the beepr package to the project?
long_process()
beepr::beep() # How do I make this call?
You could technically disable sandboxing, which is where renv prevents packages installed in the system library from being made available in the project (which is why you wouldn't be able to use beepr::beep() in your example. You can change your user configuration easily, just see the documentation from env. The setting here would be renv.config.sandbox.enabled.
However, I don't think that's the best option. Depending on the snapshot type settings described in ?renv::snapshot, you needn't worry about installing beepr but it getting added to the lock file.
You can check or set the snapshot type using:
renv::settings$snapshot.type()
If you install the beepr package in the environment, then depending on the type you will get:
"all": the only problematic setting. If you run snapshot with beepr actively loaded, it will be added to the lock file, which isn't what you want.
"implicit": as long as beepr isn't referenced in R code saved to the library, it won't be added to the lock file.
"explicit": only adds packages that are defined in DESCRIPTION.
"custom": as implied, is custom, but depends on files saved in the project, so would only add beepr if saved somewhere rather than just used interactively using debug.
So, in summary, unless you are using "all", you should be safe to install and use beepr! If you are using "all", then just be sure to detach("package:beepr", unload = TRUE) before running snapshot().
Answering the main title rather than the specific example used: to temporarily disable renv, use renv::deactivate(). This will mainly comment/deactivate the line source("renv/activate.R") in .Rprofile, which has the main effect of changing your library path.
Check:
proj <- "your-project-path"
## with renv
renv::activate(proj)
.libPaths()
#> [1] "your-project-path/renv/library/R-4.2/x86_64-pc-linux-gnu"
#> [2] "/usr/lib/R/library"
## without renv
renv::deactivate(proj)
.libPaths()
#> [1] "/home/usert/R/x86_64-pc-linux-gnu-library/4.2"
#> [2] "/usr/local/lib/R/site-library"
#> [3] "/usr/lib/R/site-library"
#> [4] "/usr/lib/R/library"
Created on 2022-09-10 by the reprex package (v2.0.1)
I updated my Mac to OS10 and attempting to run RStudio Knit, and get the error:
"evaluate 0.7.2 is required but 0.7 is available".
I tried this and did not fixed the issue:
remove.packages("evaluate")
install.packages("evaluate")
Any help would be appreciated.
Try setting up the below option and by rerunning the code.
getOption("repos")
options(repos = c(CRAN = "https://cran.rstudio.org"))
It also happened to me. I downloaded evaluate zip file from here https://cran.rstudio.com/web/packages/evaluate/index.html
and then manually installed it in R Studio (Tools-InstallPackages-zip file).
Good luck !
install.packages('evaluate')
Warning in install.packages :
unable to access index for repository HTTP://cran.rstudio.com/bin/windows/contrib/3.4:
cannot open URL 'HTTP://cran.rstudio.com/bin/windows/contrib/3.4/PACKAGES'
When you compile the update or remove sentences, if the output like this, you could make some settings, since maybe the problem is your internet. Follow the steps:
Open Rstudio.
Click tools.
Choose global options->packages.
Modify CRAN to the country you living. like, China or Japan. Cause your browser maybe work only you do this.
I want to use packrat on a Windows 7 machine with no internet connection.
I have downloaded all binary packages from http://cran.r-project.org/bin/windows/contrib/3.1/ into the local folder C:/xyz/CRAN_3_1.
The problem is now that
packrat::init(options=list(local.repos="C:/xyz/CRAN_3_1"))
throws a bunch of warnings and errors like
Warning: unable to access index for repository http://cran.rstudio/bin/...
Warning: unable to access index for repository http://cran.rstudio/src/...
Fetching sources for Rcpp (0.11.4) ... Failed
Package Rcpp not available in repository or locally
As it seems packrat tries to find
the binary version of Rcpp on CRAN (fails since there is no internet connection)
the source of Rcpp on CRAN (fails since there is no internet connection)
the local source of the package (fails since I only have the binaries)
What I don't understand is why packrat does not also search for the local binary package...
Question 1: I could download the source CRAN repository to get around this problem. But I would like to know from you guys whether there is an easier solution to this, i.e., whether it is possible to make packrat accept a local binary repo.
Question 2: When I create my own package myPackage with packrat enabled, will the myPackage-specific local packrat library also be included in the package? That is, assume that I give the binary myPackage zip File to one of my colleagues who does not have one of the packages that myPackage depends on (let's say Rcpp). Will Rcpp be included in myPackage when I use packrat? Or does my colleague have to install Rcpp himself?
I managed to hack around this problem. Please bear in mind that I have never used packrat before and that I do not know its "proper" behaviour. But my impression is that the hack works.
Here is how I did it:
Open your project, load packrat via library(packrat)
type fixInNamespace("snapshotImpl",ns="packrat") - a window opens - copy its content into the clipboard
Go to /yourProjDir/ and create a file snapshotImplFix.R
Copy the clipboard's content into this file ...
... but change the first line to
snapshotImplFix=function (project, available = NULL, lib.loc = libDir(project),
dry.run = FALSE, ignore.stale = FALSE, prompt = interactive(),
auto.snapshot = FALSE, verbose = TRUE, fallback.ok = FALSE,
snapshot.sources = FALSE)
Note snapshot.sources = FALSE! Save and close the file.
Create /yourProjDir/.Rprofile and add
setHook(packageEvent("packrat","onLoad"),function(...) {
source("./snapshotImplFix.R");
tmpfun=get("snapshotImpl",envir=asNamespace("packrat"));
environment(snapshotImplFix)=environment(tmpfun);
utils::assignInNamespace(x="snapshotImpl",value=snapshotImplFix,ns="packrat");})
Points 2-6 fix the problem with the snapshot.sources argument being TRUE by default (I did not find a better way to change that...)
Finally, we have to tell packrat to take our local repository. It's important that you have the right folder structure. Therefore I moved the repo from C:/xyz/CRAN_3_1 to C:/xyz/CRAN_3_1/bin/windows/contrib/3.1. Do not forget to run library(tools);write_PACKAGES("C:/xyz/CRAN_3_1/bin/windows/contrib/3.1"); if you also have to move your files.
Open yourProjDir/.Rprofile again and add at the end
local({r=getOption("repos");r["CRAN"]="file:///C:/xyz/CRAN_3_1";r["CRANextra"]=r["CRAN"];options(repos=r)})
Note the 3 / right after file! Save and exit file.
Close the project and re-open.
Now you can execute packrat::init() and it should run without errors.
It would be great if someone with more experience regarding packrat could give his/her input so that I can be sure that this hack works. Any pointers to proper solutions are highly appreciated, of course.
I am trying to use the library libspatialite to extend sqlite on a NetBSD platform. I've taken the first step of creating a package for libspatialite in pkgsrc (libspatialite-4.1.1). The package appears to work; pkg_info says it's installed and I've verified that the files from PLIST (in code chunk below) have been installed in /usr/pkg/. However, when I try to install the package I built for spatialite-tools, configure says that libspatialite isn't installed. Also I can't figure out how to load the library in sqlite3 with load_extenstion(X,Y); what is the library file referred to in the documentation?
pkgsrc/databases/libsqlite/PLIST:
#comment $NetBSD$
include/spatialite.h
include/spatialite/debug.h
include/spatialite/gaiaaux.h
include/spatialite/gaiaexif.h
include/spatialite/gaiageo.h
include/spatialite/geopackage.h
include/spatialite/gg_advanced.h
include/spatialite/gg_const.h
include/spatialite/gg_core.h
include/spatialite/gg_dxf.h
include/spatialite/gg_dynamic.h
include/spatialite/gg_formats.h
include/spatialite/gg_mbr.h
include/spatialite/gg_structs.h
include/spatialite/gg_wfs.h
include/spatialite/gg_xml.h
include/spatialite/spatialite.h
include/spatialite/sqlite.h
lib/libspatialite.la
lib/pkgconfig/spatialite.pc
Do you have a buildlink3.mk file in the libspatialite package?
If not:
In order to avoid a package building against implicit dependencies pkgsrc only makes libraries which have been explicitly listed visible to the building package.
This stop the issue of a package picking up an optional dependency which just happens to be installed, then building a binary package which uses that library but does not have it listed in the package metadata. The resultant binary package will work fine on that system... until the optional dependency is removed, and will fail on any other system without that hidden dependency.
Anyway... buildlink3.mk files are used in pkgsrc to make the necessary files visible during a build. A libspatialite buildlink3.mk might look like the below (adjust 1.0 to the current lib version)
# $NetBSD$
BUILDLINK_TREE+= libspatialite
.if !defined(LIBSPATIALITE_BUILDLINK3_MK)
LIBSPATIALITE_BUILDLINK3_MK:=
BUILDLINK_API_DEPENDS.libspatialite+=libspatialite>=1.0
BUILDLINK_PKGSRCDIR.libspatialite?= ../../devel/libspatialite
BUILDLINK_LIBDIRS.libspatialite+= lib/spatialite
BUILDLINK_RPATHDIRS.libspatialite+= lib/spatialite
BUILDLINK_INCDIRS.libspatialite+= include/spatialite
.endif # LIBSPATIALITE_BUILDLINK3_MK
BUILDLINK_TREE+= -libspatialite
Then in the depending package add something like:
.include "../../devel/libspatialite/buildlink3.mk"