I am encountering package compatibility issues within my global Julia environment for specific packages I want to use in a Jupyter notebook. Is there a way to tell IJulia to use a different environment instead of my global one?
The default IJulia kernel sets --project=#. so the most convenient way (IMO) is to just keep your project in the same folder as the notebook. The result is that the correct project is used from the start and you don't have to worry about activating it while in the notebook.
You can always start up a notebook, and within a cell run
using Pkg
Pkg.activate("./path/to/folder")
When starting the notebook type:
notebook(dir="/path/to/your/environment/")
This will launch Jupyter notebook loading the environment (Project.toml) in the directory that you have specified. If there is no Project.toml in that directory, the default (global) environment will be used.
Depending on the complexity of your setup, you might want to consider Lmod
I use this with a module hierarchy: 1. Core module, 2. Compiler modules, MPI modules.
With this, its possible to quickly switch between difference branches.
Related
Is there a built-in IJulia function that list the kernels I have installed? I installed a kernel using installkernel and some time after I wanted to remove it with rm. I could remember the name I gave it but not the path IJulia uses to install the kernels, so I had to manually search my system.
It would be handy if IJulia could list the names and/or paths and I'm surprised that I couldn't find anything.
You can use IJulia.kerneldir() to get the directory holding kernels.
Then if you do e.g. readdir(IJulia.kerneldir(), join=true) you get a vector of directory names that can be used in rm.
I downloaded someone else's project and the structure is as follows:
project/
notebooks/
notebook_a.ipynb
notebook_b.ipynb
library/
Manifest.toml
Project.toml
src/
test/
In the notebooks I would like to import library, and install its dependencies within its own evironment.
Following the sugestions here, I can do
using Pkg
Pkg.activate("../library/")
but I wonder if I could install a kernel that has the project directory specified and automatically activates the library environment. What should I pass to IJulia's installkernel? "--project=..." what?
I use conda regularly and this confused me because I thought that running notebook once the environment is activated in the command line would have the right environment in the notebook, but this was not the case.
IJulia starts its own Julia process and hence is not using environment settings from its master.
By default IJulia sets the environment (Project.toml) from the folder it was started. The most convenient thing would be to move the notebooks folder to be subfolder of library and then just run:
notebook(dir="/path/to/project/library")
If you do not want to change the folder structure you still need to run:
notebook(dir="/path/to/project/notebooks")
Once in the notebook you need to run:
using Pkg
pkg"activate /path/to/project/library"
After having set the path for the default working directory as well as my first (and only) project within RStudio options I wonder why RStudio keeps creating an empty folder named "R" within my "/home" directory every time it is started.
Is there any file I could delete/edit (eventually create) to stop this annoying behaviour and if so, where is it located ?
System: Linux Mint v. 19.3
Software: RStudio v. 1.3.959 / R version 3.4.4
Thanks in advance for any hints.
Yes, you can prevent the creation of the R directory — R is configurable via a set of environment variables.
However, setting these correctly isn’t trivial. The first issue is that many R packages are sensitive to the R version they’re installed with. If you upgrade R and try to load the existing package, it may break. Therefore, the R package library path should be specific to the R version.
On clusters, an additional issue is that the same library path might be read by various cluster nodes that run on different architectures; this is rare, but it happens. In such cases, compiled R packages might need to be different depending on the architecture.
Consequently, in general the R library path needs to be specific both to the R version and the system architecture.
Next, even if you configure an alternative path R will silently ignore it if it doesn’t exist. So be sure to manually create the directory that you’ve configured.
Lastly, where to put this configuration? One option would be to put it into the user environment file, the path of which can be specified with the environment variable R_ENVIRON_USER — it defaults to $HOME/.Renviron. This isn’t ideal though, because it means the user can’t temporarily override this setting when calling R: variables in this file override the calling environment.
Instead, I recommend setting this in the user profile (e.g. $HOME/.profile). However, when you use a desktop launcher to launch your RStudio, this file won’t be read, so be sure to edit your *.desktop file accordingly.1
So in sum, add the following to your $HOME/.profile:
export R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v
And make sure this directory exists: re-source ~/.profile (launching a new shell inside the current one is not enough), and execute
mkdir -p "$(Rscript -e 'cat(Sys.getenv("R_LIBS_USER"))')"
The above is using the XDG base dir specification, which is the de-facto standard on Linux systems.2 The path is using the placeholders %p and %v. R will fill these in with the system platform and the R version (in the form major.minor), respectively.
If you want to use a custom R configuration file (“user profile”) and/or R environment file, I suggest setting their location in the same way, by configuring R_PROFILE_USER and R_ENVIRON_USER (since their default location, once again, is in the user home directory):
export R_PROFILE_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/rprofile
export R_ENVIRON_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/renviron
1 I don’t have a Linux desktop system but I believe that editing the Env entry to the following should do it:
Exec=env R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v /path/to/rstudio
2 Other systems require different handling. On macOS, the canonical setting for the library location would be $HOME/Library/Application Support/R/library/%v. However, setting environment variables on macOS for GUI applications is frustratingly complicated.
On Windows, the canonical location is %LOCALAPPDATA%/R/library/%v. To set this variable, use [Environment]::SetEnvironmentVariable in PowerShell or, when using cmd.exe, use setx.
I am new to IPython Notebook. I am using the Anaconda distribution on CrunchBang (Waldorf). My development cycle is as follows:
1. Open Spyder.
2. Open the .py file if not already loaded
3. Start IPython Notebook
4. Open the specific notebook from the main IPython screen
5. Select Cell/Run All
6. Note errors. If none goto step 11.
7. Save and close the notebook
8. Shutdown the notebook from main IPython screen
9. Correct errors in Spyder and save
10. go to step 4
11. Move on to the next part of the project and start the process over.
Is there a better approach for a noob? This really gets monotonous although I am learning quite a bit.
Thanks in advance
Forget Spyder for the time being just use the IPython notebook.
1, write code in notebook
2. test it
3. when done if needed make a py file...
You really will only need Spyder later for starting out it just complicates things for no gain
Use Spyder and .py files for writing big functions, classes, modules, tests, etc.
Use IPython notebooks for interactive work where you want to keep the output together with the code (e.g. data processing and analysis, demos, etc.).
To add to Ian's answer, another useful tool is the autoreload extension, which reloads modules automatically when they are changed.
To use, type into your IPython console or notebook:
%load_ext autoreload
%autoreload 2
For example:
This way you can work on a Python file and an IPython notebook at the same time, without having to reload the Python file after each change.
In addition to #dartdog's answer about developing directly in the notebook, if you must edit .py files used by the notebook then note the reload function which allows you to re-import already imported modules without having to shutdown and reopen the notebook.
I'm trying to build my own package using Windows. I installed everything I need, and running R CMD build mypackage and R CMD INSTALL mypackage seem to run fine. when I run the build command, though, I get a warning from cygwin:
cygwin warning:
MS-DOS style path detected: C:/Documents and Settings/e_sander/My Documents/mypackage_1.0.tar.gz
Preferred POSIX equivalent is: /cygdrive/c/Documents and Settings/e_sander/My Documents/mypackage_1.0.tar.gz
CYGWIN environment variable option "nodosfilewarning"turns off this warning. Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I did go to the recommended website, but I don't know much about cygwin or linux so I'm not sure there's anything I need to do. I realize that using the MS-DOS style path is deprecated and not recommended in cygwin, but I'm not sure how to change that, since I'm running Windows and that's the path I need. I also haven't noticed any problems with my package, at least when I install it to my computer (and although I haven't used the tarball, I've opened it and everything looks fine). So here's what I'm trying to figure out:
Does leaving the path as is affect my package in any way?
If so, how could it adversely affect my package?
How do I change the path to make cygwin happy?
This is just a warning and it tells you how to disable it. It doesn't affect anything. If you want it to go away, run this from your shell:
export CYGWIN="nodosfilewarning"
Or you could mount C: to /c/ (see man mount).
Does leaving the path as is affect my package in any way?
- No, it is just a warning.
If so, how could it adversely affect my package?
- N/A
How do I change the path to make cygwin happy?
- Set the environment variable as the output states. There are multiple ways to do this; I chose to go with a solution that handles the issue across any invoked environment that parses or inherits from the windows environment by using the "Rapid Environment Editor" program to add a User Variable named CYGWIN with a value nodosfilewarning. But if you wanted you could add it through the control panel using Add environment variables for your account.