Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
What are best practices to updating R and packages, when you have a stable programming environment, to avoid "breaking" code/package functionality?
Should you download a new update of R or package when it's out? Or is a "if it isn't broken don't fix it" mentality preferred.
Thanks.
For your programming environment, update unless you have good reason not to, and maintain a good test suite for your in-house code. For projects with special needs, use renv to control versions of packages.
For your production environment, use the renv package to keep package versions locked down, and upgrade in a controlled manner if there is an explicit need.
CRAN goes to great lengths to ensure that all current packages work with all other current packages under the current version of R.
So I tend to
update to new R versions as soon as theu becomes available
update CRAN packages (using a helper script) daily or near daily.
That has worked for more than two decades, including "in production". I have not needed renv but, as they say, different strokes for different folks. I also stay away from packages I suspect may break, and try not to install "random" github snapshots.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
A colleague needs to set up a dev, stage and production environment on our server and he is asking what this means for how to run our R codes. Frankly, I do not know. My intuitive solution would be to have three different servers, so the installed R packages do not conflict. But for now, the environments should be on the same server. I am not sure how to achieve this. How can we run several versions of a package side by side? For example, using different .libPaths to be able to host different packages side by side?
What is the proper way to set this up?
PS. I hope I expressed myself clear enough, as I do not have any experience with this stuff.
Every GNU program allows you to prefix its installation (and more, as eg a suffix or prefix appended to the executable).
We use that in the 'how to build R-devel script' I posted years and and still use, directly and eg in the Dockerfile scripts for Rocker.
This generalizes easily. Use different configurations (with/without (memory) profiling, UBSAN, ...) and/or versions to you content, place them next to each other in /opt/R or /usr/local/lib/R or ... and just use them as every R installation has its own separate file tree. One easy way to access them differently is via $PATH, another is to just have front-end scripts (or shell aliases) R-prod, R-qa, R-dev, etc pp
You will have to think through of you want a common .libPaths() (for, say, common dependencies) or whether you want to reinstall all libraries for each. The latter is the default.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I just created my first R package and started my first GitHub repo. The main function of the R package and some data files are still in development and I would like to track changes with colleagues on GitHub.
Should my repo consist of prepackaged files (pre-Rd) or packaged files? Every other R repo I've seen has packaged files but I assume they aren't still in the initial development phase.
If you want to build a package then you should start building it with the appropriate directories and supplemental files, but you just work on developing your source code until you've created a minimum viable product, at which one you can create an install-able package and update it as often as you like.
Truly, the sooner that you create the package the better because it paves the way to the best practice of iterative development and it also helps you to spot bugs as you make changes to your source code.
There's a good tutorial on building packages on GitHub at this blog I like called Hack-R.com (shameless self-promotion).
http://hack-r.com/write-an-r-package-from-scratch-with-github/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
renjin's approach seems to be great. However compatibility to base R is not 100% and there are lots of very interesting packages out there which do not / only partly work with renjin.
I am fairly new to renjin but really would like to use it. But some important packages like the forecast package are missing - or at least the tests do not run in renjin.
To focus this question a little bit more I started to port the forecast package. You will find the current status https://github.com/geoHeil/forecast However it still contains errors.
Why does the build crash if I delete the man folder where the R documentation resides in?
I understand that other referenced packages may cause problems on import but even if they are disabled I still cannot load the namespace file to run my simple example hamcrest test-case
Why does it try to load the package from CRAN? Why is no default package specified?
This is the error message:
No default packages specified
Could not load this project's namespace (it may not have one)
org.renjin.eval.EvalException: Could not load package org.renjin.cran:forecast
Is there a better reference as http://docs.renjin.org/en/latest/writing-renjin-extensions.html to show how to move CRAN packages in a renjin compatible format?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am a beginner with R.
I found that there are two project website named CRAN and R-Forge.
What exactly is the difference between these two?
The CRAN, or Comprehensive R Archive Network, is the official distribution network of R packages. To publish an R package, you upload its source code to the CRAN FTP server. The package is then tested, built for the different platforms, and made available on the different mirrors around the world for download and install with install.packages().
R-forge is a package development web site which provides package development tools : source control, bugs tracking, mailing lists, etc. These are tools that are not provided by CRAN, which is only a distribution network.
CRAN is R's main package repository. It stores source code and builds binaries of packages. It is the default repository, so you can access packages in it with a factory-fresh copy of R. It is the first place people will look for stable versions of packages. (Bioinformatics packages tend to be on Bioconductor instead.)
R-Forge (and RForge) are package development environments as well as repositories. That means they include (SVN) source control, bug tracking and other features. You can get development versions of packages from these. Alternatives include github, Google code and bitbucket.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I learnt from the web that Revolution R allows multi-threading and optimize running of my R-scripts.
My question is: after installation of Revolution R, if I run my R-script under Revolution R environment, will it automatically optimize running of my R-script? Or I need to modify my R-script in order to allow Revolution R to optimize running of my R-script?
Thanks a lot.
I think your terminology may need some refinement. You may need to distinguish multi-processing from multi-threading. Revolution R does link to a multithreaded BLAS library for Windows that might otherwise not be available unless you compiled your version. Whether or not that will improve your performance is apparently somewhat dependent on what functions you use.
To use multi-processing in R, you will need set up your machine resources appropriately and then use code that distributes the parallizable tasks. Those seem to be the applications you are thinking about when you ask about modifying your scripts. Revo-R used to have advantages here over regular R, but for the last couple of versions, the 'parallel' package has been available to all useRs.
Revo R has multithreaded BLAS, this does not require a change in your scripts.
And GNU R, or Standard R, can of course also use multithreaded BLAS as detailed in Appendix A.3.1 of the R Installation and Administration manual.