I thought I'd give Nuclide a try and after running apm install nuclide-installer I went to the packages tab and searched for "nuclide".
Unfortunately the docs says:
From there, filter your installed packages by nuclide- and you should
see quite a few results!
I see 1 nuclide-language-hack, which i'm guessing doesn't equal "quite a few".
Has something gone wrong? How many packages should there be?
Nuclide is a single Atom package named 'nuclide'. Install it with apm install nuclide.
Prior to Nuclide's Unified Package released on 2016-01-13, Nuclide consisted of 44 separate Atom packages. At the time of my original answer, which is still below, Nuclide was 12 packages.
Original answer:
The list of nuclide- packages is at 12 at the moment:
https://github.com/facebooknuclideapm/nuclide-installer/blob/master/lib/config.json
Since you install nuclide-installer itself, that makes a total of 13 nuclide- packages you should see after installation. You should be able to watch that file in the near future for a list of Nuclide packages.
Related
I am creating my first package, which shall be installed through Github. I thought that Rtools was needed only for the person creating it. However, people that tried to install it using Github were asked to update Rtools. Is this really necessary?
Doing some research, I found this: https://community.rstudio.com/t/missing-rtools-should-i-be-worried/27817
One of the answers says the following:
"This means that if you are going to install packages that need
compilation, you also have to install Rtools in your system. "
This is the repo with the package: https://github.com/datazoompuc/PNAD_Covid/tree/master/R/datazoom_pnad_covid
What does this actually mean? How do I know that my package needs compilation?
I thought that Rtools was needed only for the person creating it.
Yes, if and only if you distribute it as a binary. Then the creator uses Rtools to compile and link, and the user just installs, and enjoys.
That is how CRAN works as CRAN compiles for Windows users.
GitHub, however, is foremost a source repository so the installation from GitHub is using a source mode ... and every user will need to compile, and hence have Rtools. (Unless the package and all its depedencies are R-code only.)
You can also have a package repository on GitHub using e.g. the drat package to create it, but that is getting us a little further from the original question.
Your package "needs compilation" — i.e. needs Rtools to install from source (on Windows) — if it contains C or Fortran components, i.e. if you have anything in the src/ directory of your package ...
If you, the package author, don't know if you have C or Fortran code as part of your package, then you almost certainly don't.
It's quite possible that devtools is being overzealous, i.e. detecting that users have a not-most-current Rtools and suggesting (requiring??) that they update it, even though it's not needed for this installation.
I asked a similar question a couple months ago, but the package, website, and code in question have since been updated and the solution I used previously is no longer effective.
The issue is that I am unable to install a particular package in R.
The new code provided for installation of the DeclareDesign package is as follows (source):
install.packages("devtools")
devtools::install_github("DeclareDesign/DeclareDesign")
I've provided a screenshot of the error that I get when I try to run the above code. It looks to me like the problem is with the included 'estimatr' package, which apparently then causes the entire installation to fail.
How do I get this to work?
Your installation failed because devtools is trying to install estimatr from source, but you don't have the appropriate toolchain available to build it.
DeclareDesign now has a drat repository with pre-built binary packages for Mac and Windows, which should obviate the need to install Xcode or Rtools.
install.packages("DeclareDesign", repos="http://r.declaredesign.org")
DeclareDesign is now on CRAN, so you can install via
install.packages("DeclareDesign")
This question already has an answer here:
How do I install the latest version of rgl?
(1 answer)
Closed 6 years ago.
It was surprising to find install_github failing with a message "SVN does not seem to be installed on your system" indicating that SVN was needed. This followed the advice from a well-known rgl installation question How do I install the latest version of rgl. I could install it manually, but I did not understand the message and posted the question in the title.
After some messy investigation we found that it was due to a remote configuration line in the rgl package DESCRIPTION file that was not needed. This answer is in the comments to the answer marked correct.
However we also found that much of the guidance in the original question was out-of-date and it has since been modified.
Screen shot:
Edited: the Github mirror is up to date again, so all of the methods listed in How do I install the latest version of rgl? should be fine. If the server dies again, you can always use
install.packages() or use SVN.
The install_github() method should no longer require an SVN install.
You can install from RForge and any other SVN repo using the proper SVN variant of install_github(). The devtools package has install_svn, and so do the lighter-weight alternatives such as the remotes packages.
But in all these cases you still need ... an SVN client to download from an SVN repo. Which makes some sense.
What you can do, however, using just git is to use the read-only mirror every CRAN package has on GitHub. For rgl the GitHub mirror repo is here and I would expect to be successful in using install_github against that repo.
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.
Problem:
C:\>Rcmd.exe INSTALL --build --library=C:/Users/local_aphalo/Documents/R/win-library/3.0 photobiology
C:\>Rcmd.exe INSTALL --build --library=C:/Users/local_aphalo/Documents/R/win-library/3.0 photobiology_0.2.6.tar.gz
The first command (as used by RStudio) builds a ZIP file that is missing the vignettes.
The second command builds a ZIP that includes the vignettes.
Using R CMD instead of Rcmd.exe makes no difference. The .tar.gz was built immediately before attempting to build the .zip file, from exactly the same source files, from within RStudio (which uses Rcmd.exe build photobiology).
The vignettes are coded in .Snw files using knitr, documentation and NAMESPACE use ROxygen2. The problem happens on all of the packages that I have tried to build, but they are very similarly coded. Only one of them uses Rcpp.
When installing the package for use from within RStudio, installing from .tar.gz installs vignettes just fine. If installing from .zip, whether vignettes get installed or not, depends on whether the .zip files contains them or not (which depends on which of the two commands at the top of this message was used to build the .zip file).
I am using R 3.0.1, and also tried a couple of R 3.0.1 patched builds a few days back. I am mostly using Windows 7 (both 32 bit, and 64 bit), I tried once under Ubuntu 64bit, and the problem is reproducible. I first noticed the problem when using RStudio (0.97 and 0.98) and posted a message in the RStudio forum, but have received no answer in a couple of weeks. I have found at least another relatively old post about this problem in the RStudio website forum, but it has not been answered. Today, I investigated a bit further, and the problem is clearly not related to RStudio, as I can reproduce it through the command line.
The question is: Is this behavior a feature? a bug? or I am missing just an option in the command used?
Of course, I can easily work around the problem at the command line by using the .tar.gz file to build the .zip file, but as I think the preferred way of building a package is by just supplying the package name as argument.
Thanks for any insights on the origin of this problem.
I think this is a feature:
if you're installing from source, vignettes are always built
if you're installing from a binary, they're not built, and will only be available if they were built when the binary was made
This approach means that you can distribute vignettes in binary packages to people who might not be able to build them from source.