My package is hosted in github, and user can install it through devtools::install_github.
Now I'm using pkgdown to generate documentation site, which created a 10M docs folder. Then I found devtools::install_github always download the whole master zip ball which become quite slow.
I tried to exclude the docs folder with these attempts:
.Rbuildignore, turned out it's only about bundled package, while install_github is installing source package so it doesn't work.
put package in pkg folder, put the generated docs folder out of pkg folder. However the whole master zip ball is always downloaded, even with subdir = "pkg" specified.
put development in a branch, and to create a special package branch without docs folder. Merge two branch but let package branch exclude docs folder. I tried make .gitignore to be branch specific but it doesn't seem to work. This seemed to be impossible.
My newest attempt is to create a separate repo solely for the website, just let pkgdown create the website in that folder like build_site(path = "../docsite/docs"). This should solve the problem and is simple and clean. The only imperfection is the website url will not be the usually pattern.
EDIT: with the latest version of pkgdown, there is no path parameter anymore, you need to specify it in the site configuration yaml, which works better (you don't need to specify it in every command).
Related
I work in a corporate environment that uses Microsoft Windows Defender Application Control (WDAC) to provide security. This blocks unsigned EXE and DLL files from being installed on devices. R packages which use DLLs fail to install. The workaround to this is provide an R installation from an approved central source which also copies over a default set of packages, such as tidyverse, data.table etc. to the R library. Users can continue to install additional packages which are built with native R, but run into issues if they try to install, build from source, or update packages with DLL files in.
Is there a way to check whether a package uses DLL files in advance of installation?
Output something like:-
check_dll(foo)
result: "This package and its dependencies have no DLL files. You can install this package"
check_dll(bar)
result: "bar does not have any DLL files, but one dependency, OOF, uses DLL files.
You have already have a version of OOF installed so it should be safe to install bar"
check_dll(foobar)
result: "foobar has a DLL. Do not attempt to install foobar".
check_dll(RABOOF)
result: "RABOOF does not have any DLL files, but one of it's dependencies,
foobar, does have a DLL file. Do not attempt to install RABOOF".
tools::package_dependencies() will list the package dependencies, but nothing else.
Downloading the zip file from CRAN and inspecting it for a libs/x64 folder with contents will work, but seems a heavyweight approach. Theoretically if a package has lots of dependencies this could result in downloading a lot of files unnecessarily.
Look for the NeedsCompilation field in the DESCRIPTION file. If it is "yes", there will be a DLL. If it is "no", there probably won't be. (If it is not there, the package wasn't built properly, so all bets are off.)
The test is not perfect, because packages can put DLLs into the inst folder to get them installed without compiling them, though CRAN isn't supposed to allow that: "Source packages may not contain any form of binary executable code." But packages like pak (mentioned in the comments) may be allowed to get around this rule, e.g. by downloading binaries, so the test isn't perfect. You will also need to put together a blacklist of packages that will fail your WDAC tests even though they claim not to need compilation, containing pak and others like it.
The NeedsCompilation field is included as a column of the result of available.packages(), so it is very easy to access without trying to install the package.
I have accepted the answer from user2554330 as the best solution. It makes use of the normal set of commands used for package management; and the matrix generated by available.packages() can be passed to tools::package_dependencies(), removing the need for multiple internet queries.
For completeness I am documenting another possible solution. A script could query the unofficial CRAN Github mirror https://docs.r-hub.io/#cranatgh and look for a /src directory in each package project.
I have a computer behind a very restrictive proxy server it only allows me to surf the web and download programs it does not allow programs like the Atom text editor to download it's packages.
My question is how do I install them using only browser based downloads?
It is certainly possible:
Find the package you want to install, for example the activate-power-mode package.
Click on the Repo button to go to the GitHub repository.
Click Releases towards the top of the UI, then click on the most recent release, 0.4.1 in this case.
Download the source code release in either Zip or GZip depending on your platform.
Extract the content of the archive to a known permanent location, I have chosen:
C:\Source\Atom
Run the following command from your terminal / command prompt (make sure to include quotes around the path):
apm link "C:\Source\Atom\activate-power-mode-0.4.1"
Restart or Reload Ctrl-Alt-R Atom and the package will now be installed.
You can alternatively extract the package directly to your ~/.atom/packages folder however you will have to rename the folder to exactly match the name of the package, additionally uninstalling the package from Atom will delete the files which could be annoying if it is an accidental deletion.
Because of package dependencies a safest bet is this:
Install package normally on connected computer
Copy contents from your ~/.atom/packages
Paste contents to ~/.atom/packages on offline computer
Restart Atom
At least this worked for me like a charm.
The answer of Richard Slater is informative and the answer of Andriy Buday could look less professional. But, in my case, the answer of Andriy Buday was also very important.
I tried to install two packages atom-beautify and prettier-atom by following the answer of Richard Slater and had some problems of not being able to find some modules. It was not only me who had these problems. Consider checking the following links.
The issue of "cannot find module event-kit"
https://github.com/Glavin001/atom-beautify/issues/1734
https://github.com/Glavin001/atom-beautify/issues/1366#issuecomment-269716306
When I decompressed a file (atom-beautify-0.30.3.tar.gz) I received from GitHub respository, I could find out directories like appveyor, docs, and examples. But I could not find out a directory named node_modules which was present when I installed this package atom-beautify using Atom Editor online.
To check if the absence of directory node_modules is the only problem, I went through the following steps.
Start Atom Editor.
Install atom-beautify using Atom Editor online like the answer of Andriy Buday suggests.
Close Atom Editor.
Move atom-beautify directory from ~/.atom/packages (that was %HOMEDIRECTORY%%HOMEPATH%.atom\packages in my case because I used cmd on Windows 10) to somewhere else.
Decompress atom-beautify-0.30.3.tar.gz and move or copy atom-beautify-0.30.3 directory from this decompressed result into %HOMEDIRECTORY%%HOMEPATH%.atom\packages as the answer of Andriy Buday suggests.
Rename directory %HOMEDIRECTORY%%HOMEPATH%.atom\packages\atom-beautify-0.30.3 to %HOMEDIRECTORY%%HOMEPATH%.atom\packages\atom-beautify as the answer of Richard Slater suggests.
Move or copy node_modules directory from the directory moved at step 4 into %HOMEDIRECTORY%%HOMEPATH%.atom\packages\atom-beautify.
Start Atom Editor.
I found that no error message appeared and that package atom-beautify worked properly, thus I am thinking that absence of node_modules directory was the only problem of the file atom-beautify-0.30.3.tar.gz I received from GitHub repository.
I am afraid if it is normal that directory node_modules is not contained in the file atom-beautify-0.30.3.tar.gz downloaded from GitHub repository because of any rules I do not know yet, like placing directories like node_modules somewhere else. If there really are such rules and somebody tells me about such rules by adding an answer or a comment here, I will appreciate it a lot.
I am not sure if it is same with all other packages, but I found that it was same at least with package prettier-atom.
I wish it helps somebody.
+++++++++++++++++++++++++++
I found why the directory node_modules was not contained in atom-beautify-0.30.3.tar.gz.
I checked answers of the following link.
How can I manually download packages for atom editor and install them (manually)?
Answer by D3181 included a link to a page of http://discuss.atom.io/ (I could get a helpful answer by Alchiadus from the link) and suggested running apm install in the package's directory. If it is necessary to use a file downloaded from GitHub repository like atom-beautify-0.30.3.tar.gz, it is necessary to run apm install in the package's directory before copying or moving into %HOMEDIRECTORY%%HOMEPATH%\.atom\package (~/.atom/package in case of *nix) of the offline computer.
Decompress the file downloaded from GitHub repository like atom-beautify-0.30.3.tar.gz.
Go into the directory like atom-beautify-0.30.3 of the decompressed result.
Run apm install on an online computer. (If the directory of apm.cmd is not in PATH, run {directory of apm.cmd}\apm.cmd install.)
Rename directory like atom-beautify-0.30.3 to the correct name of the package like atom-beautify.
Move directory with the correct name of the package like atom-beautify into %HOMEDIRECTORY%%HOMEPATH%\.atom\packages of the offline computer.
Run Atom Editor on the offline computer and check if the package works properly.
It seems normal that the directory node_modules is not included the the compressed file downloaded from GitHub repository.
I have been using git for a while but just recently started using packrat. I would like my repository to be self contained but at the same time I do not want to include CRAN packages as they are available. It seems once R is opened in a project with packrat it will try to use packages from project library; if they are not available then it will try to install from src in the project library; if they are not available it will look at libraries installed in that computer. If a library is not available in the computer; would it look at CRAN next?
What files should I include in my git repo as a minimum (e.g., packrat.lock)?
You can choose to set an external CRAN-like repository with the source tarballs of the packages and their versions that you'd like available for your project. The default behaviour, however, is to look to CRAN next, as you've identified in your question. Check out the packrat.lock file, you will see that for each package you use in packrat, there is an option called source: CRAN (if you've downloaded the file from CRAN, that is).
When you have a locally stored package source file, the contents of the lockout for said package change to the following:
Package: FooPackage
Source: source
Version: 0.4-4
Hash: 44foo4036fb68e9foo9027048d28
SourcePath: /Users/MyName/Documents/code/myrepo/RNetica
I'm a bit unclear on your final question: What files should I include in my git repo as a minimum (e.g., packrat.lock)? But I'm going to take this as a) combination of what files should be present for packrat to run, and b) which of those files should be committed to the git-repo. To answer the first question, I illustrate with initialising packrat on an existing R project.
When you run packrat::init(), two important things happen (among others):
1. All the packrat scaffolding, including source tarballs etc are created under: PackageName/packrat/.
2. packrat/lib*/ is added to your .gitignore file.
So from this, we can see that anything under packrat/lib*/ doesn't need to be committed to your git-repo. This leaves the following 3 files to be committed:
packrat/init.R
packrat/packrat.lock
packrat/packrat.opts
packrat.lock is needed for collaborating with others through a version control system; it helps keep your private libraries in sync. packrat.opts allows you to specify different project specific options for packrat. The file is automatically generated using get_opts and set_opts. Committing this file to the git-repo will ensure that any options you specify are maintained for all collaborators. A final file to be committed to the repo is .Rprofile. This file tells R to use the private package library (when R is started from the project directory).
Depending on your needs, you can choose to commit the source tar balls to the repository, or not. If you don't want them available in your git-repo, you simply add packrat/src/ to the .gitignore. But, this will mean that anyone accessing the git-repo will not have access to the package source code, and the files will be downloaded from CRAN, or from wherever the source line dictates within the packrat.lock file.
From your question, it sounds like committing the packrat/src/ folder contents to your repo might be what you need.
I'd like to understand: when I install a package, where is is stored locally?
I mean the directory structure that I can see on github. I've been looking in username/.meteor/packages.
I can indeed see a list of my packages in this directory but the package content doesn't seem to be there.
Run "meteor remove owner:packageName" to get rid of the external package.
Clone the package and copy or link it to /yourApp/packages/packageName
Run "meteor add owner:packageName" to add the local version.
That's all.
See: https://www.youtube.com/watch?v=flGh4nHnETg
I'm at a loss as to how to install the RBloomberg package. The only source for the files seems to be GitHub. The offered zip file is called blpwrapper-master.zip which embeds an rbloomberg folder. When I try to install the zip file (in RStudio), I get an error message that it cannot open a compressed file. I rezipped just the rbloomberg folder, but that led nowhere either. How does one go about this?
In general things can be installed from Github using the devtools package. For example:
library("devtools")
install_github("username/packagename")
I don't know who authors so Rbloomberg, but you can swap in the appropriate Github username in the above.
Note: Sometimes this won't work because a developer uses a non-traditional .git directory structure, but it should work in most cases. Indeed, that is the case here (as #rawr points out), where you need to use a slightly different path to point to package (which is in a subdirectory of the git repo):
install_github("johnlaing/blpwrapper/rbloomberg")