Pip Install R-essentials
Lien Kocurek
I just get the Solving environment message for a good hour or more before I just exit out altogether. This even occurs when I create a brand new environment without any other packages before attempting to install r-base and r-essentials.
Being a conda user for almost a year now, I thought of making this short bulletins to keep R installation in conda tidy and error-free for beginners. Here are the following suggestions from my experience
that might be a good solution for R, but Conda has an advantage in that it can handle a lot more than just R, or Python. I frequently use Conda to create an entire reproducible software stack, which can include R and Python libraries, in addition to bioinformatics tools, db engines like PostgreSQL, Celery, RabbitMQ, and even nginx.
Hi all, just came across this exact problem while trying to run a clermonTyping package. None of the other solutions listed here worked for me, but I managed to find one that did. For context, I'm running my code on a remote Ubuntu server for which I am NOT a sysadmin NOR do I have sudo privileges, which prevented me from writing to PATH/overwriting any other environment variables. My solution was as follows (all of this was typed into terminal:
With time as my knowledge improved, I learned that conda-forge is more reliable than installing from private repositories as it is tested and reviewed thoroughly by the Conda team. So here are new steps to install R.
Also r-studio available on the Anaconda package site downgrades the r-base from 4.0.3 to 3.6 version so I no longer suggest installing r-studio that way. In case if you want to use studio, just activate your R environment in conda and whichever r-base version is available in that environment, studio will pick it up. So same rstudio can run on multiple R versions by switching between different R environments in conda.
Note: You can not update R-packages installed through r-essentials especially rcurl. So it is still not a very good way of installing R. Packages such as ComplexHeatMap packages and Cairo can not be installed.
I personally prefer to have full control over what is in PATH and what is not via a simple command.If you run echo 'auto_activate_base: false' >> $HOME/.condarc this will avoid auto-activation of conda base environment upon startup of a new terminal. With conda activate you can start base (or any) environment, and this will put the respective bin folder into PATH. That makes sure that you are always explicit on what is in PATH or not. You may want to e.g. compile some software outside of conda, but that should require conda being completely turned off to avoid mixing of libs and packages. What will (via the installer afaik) always be in PATH is condabin which contains the conda executable, and this can then be used, as described above, to conveniently turn on/off environments.
A lot of problems occur because base is auto-enabled and installing into the base can cause extremely hard to debug problems. Without explicitly activating an environment conda install should refuse to work.
That being said, right now for a beginner, it is probably still best to follow the standard conda practices that are better documented at this time. Then new releases can provide a documented migration path.
Conda introduces a dbus-daemon which conflicts with the system one in some Linux distributions. This results in problems (for example with matplotlib). In my view, this is the result of two bad practices, 1- not using a hard-coded path for systems component in the OS, 2- modifying the user's $PATH on conda's side.
I would much rather have conda break and debug why its unhappy, than to have conda apply some unknown mysterious configs to my system and potentially break everything else on the system. I understand that this is a fundamental difference between "the best way to use conda" and the developers intentions on how conda should be used
(DISCLAIMER: some of the steps described here explicitly go against the official conda installation & usage instructions; beginners should follow the official guides instead before trying any of these steps, and fully understand what these steps are doing before trying them out)
0). use a fresh new conda installation for each project, dont try to manage multiple conda env's in a single conda installation, you can download Miniconda from here: , yes this wastes some disk space but it saves you a lot of headaches
1). install all the R packages you need up front with a single conda install command without specifying library versions, then let conda pick compatible libraries, then note which versions it chose, then delete the entire conda install and start over with a new fresh conda installation and run conda install again while specifying the exact versions of libraries you want based on the list conda chose for you,
1a). be careful if conda tries to update itself and/or its included Python versions because sometimes this can cause conda to break itself, if that happens then be sure to include args with conda install to lock versions of conda itself and/or Python
2). never ever run conda install ever again after the first time unless you absolutely have to (occasionally I've had to install pacakge like ncurses from conda-forge before installing anything else, but thats rare),
3). dont ever bother with conda activate, just update PATH yourself to prepend conda/bin since all your libs will be installed there by default, update and other needed env variables yourself as well,
4). keep all the commands you used for the entire process saved in a script with your project, and use a wrapper-script to correctly set the environment to run your scripts and programs (you might need to unset PYTHONPATH and PYTHONHOME, and apply other env updates that conda activate normally handles. Or if you are adventurous your wrapper script can just call conda activate and pray that it doesn't have side-effects that break something
A lot of people seem to have negative sentiment towards conda due to its tendency to try and "take over" your system, the steps described here were developed to try and prevent that while still keeping conda installations reproducible and reliable. Concerns about disk space usage from multiple complete conda installs can be mitigated somewhat by keeping full install scripts associated with each project, example;
Because we created this R environment and specified r-essentials, many popular packages have already been loaded. Check this by loading some basic libraries library(ggplot2) or library(dplyr). Convenient, eh?
This will open the jupyter notebook home screen in browser window, showing your current directory. At the top right, you can click New and see which kernels you can use to start a notebook (hopefully, Python 3 or R).
From my experience, a common issue I encountered was jupyter notebook trying to use an R version that was external to my environment (i.e. from an R version installed in my base environment or an old R version installed on my computer pre-anaconda). These issues manifest as IRKernel in jupyter notebook never becomes active or dying immediately after launch. This cause of this problem was revealed with the kernelspec command above.
Launch RStudio by typing rstudio. The first line in the RStudio console should be the same as when we launched R from the command line directly R version 3.5.1 (2018-07-02) -- "Feather Spray". To close RStudio, you can close RStudio itself, or CTRL+C in the terminal from where you launched it.
Make sure you are still in your r_3.5.1 environment (sourcing your bash profile may place you back in your base environment). From the command line (in your r_3.5.1 environment) you can now type rstu3.5 to launch RStudio. I highly recommend opening RStudio from the command line using this alias you created! I found it was a much more stable way to work with RStudio.
Another reason to not shy away from destruction is that it is a way towards a more reproducible work process. After deleting and reinstalling Anaconda (and every other conda environment to my name), I was able to easily reinstate the environment my collaborator and I share with no issues (you can rebuild!). And now, I can return to whichever R version I need for a given project by navigating between my R conda environments. How much fun is it to be organized?.
Anaconda was built with Python in mind. My motivation for this post was that it was difficult to find a working solution to partition R versions using conda environments (especially in conjunction with IRKernel and RStudio). Anaconda seems to work more succintly with python; as an example, I found that some older versions of R were not as stable as others. But R support is constantly growing! Also, check out the newly released RStudio 1.2, which will support Python
I was sitting in a presentation a few weeks ago on the R-ArcGIS bridge by Marjean Pobuda and I had a question: "Can I use the R-ArcGIS bridge in my Jupyter Notebook?" So I asked Mark Janikas (who was also attending the presentation) if this would be possible an he said, "Yes". So, after the presentation, I set out to get the R-ArcGIS bridge running in Jupyter.
The first thing I did was install the R-ArcGIS bridge. I installed it using ArcGIS Pro by following the installation instructions. I am currently using R-3.4.2 and arcgisbinding '1.0.1.208'. I can verify this by going to the Geoprocessing tab in the Options section in ArcGIS Pro.
I did not want to break my arcgispro-py3 conda environment (the default ArcGIS Pro Python environment) so the first thing I did was clone the environment. I named the cloned environment arcgispro-r. I did this from the command line as follows:
Next, I switched to the cloned environment by deactivating the arcgispro-py3 environment and activating the arcgispro-r environment. This can be done at the command line with two commands, deactivate and activate, as shown her:
After I installed r-essentials, when I launched my Jupyter Notebook, I had the option to create a Python or an R notebook. I created an R notebook. To test whether the ArcGIS-R bridge is installed and accessible to my notebook, I loaded the arcgisbinding package and checked the product version number and there it was, package version '1.0.1.208', the same one I see listed in ArcGIS Pro above!
c80f0f1006