Skip to content

how to make a loaded distribution for courses?

4 messages · Vincent Carey, Simon Urbanek, stefano iacus

#
I just taught a course based on R-2.7.0dev, where many bioconductor and CRAN
packages were required.  For the windows students, I take my
loaded R-2.7.0dev folder, in which all needed packages have been installed,
zip it, and have them unzip it in some specified location so that
there are no conflicts with existing installations.  A shortcut is set
to the new Rgui.exe, given a name that distinguishes it from existing
distributions, and this is used for the course.

Can a similar process be conducted with a MacOSX distro?  The desiderata
are that a single decompression step yields an image of R with all
desired packages, and a distinguishable icon is made available so that
the course-specific GUI is selectable from doc or finder.

---
Vince Carey, PhD
181 Longwood Ave Boston MA 02115 USA
stvjc at channing.harvard.edu

The information transmitted in this electronic communica...{{dropped:10}}
#
On Mar 8, 2008, at 6:55 AM, Vincent Carey 525-2265 wrote:

            
Yes.
There are several ways to achieve this with various levels of  
complexity:

1) Compile R with FW_VERSION=2.7-VC (or any other identifier),  
install, and compile the GUI. This guarantees a unique name that won't  
conflict with any other R installation.

2) Use R-devel from CRAN. This is easier as 1) since you don't need to  
compile anything, but by definition it will conflict with any other R- 
devel CRAN framework (or 2.7.x to be precise).

3) Use any binary and use install_name_tool to relocate it. All  
installed frameworks are linked with full paths to libraries.  
install_name_tool allows you to change those such that you can move  
the binaries anywhere.

4) Use non-framework version of R. Those are relocatable, but require  
a start script to set DYLD_LIBRARY_PATH to $R_HOME/lib. Although this  
allows you essentially to create one "R" icon containing the entire R  
(which can be place anywhere, even run from an image), care must be  
taken when compiling the GUI since there is no framework. Also it may  
be necessary to set DYLD_LIBRARY_PATH in the GUI.

1) and 2) use the regular framework location (/Library/Framerworks/ 
R.framework) such that the version to use can be selected using  
RSwitch. Note that the GUI starts always the version it was compiled  
for regardless of the RSwitch setting. Therefore by removing the  
"R.framework/Versions/Current" link before packaging you can make sure  
that the existing version is not touched.

On a Mac, I'd recommend a bit different approach that makes it easier  
for you: just get the regular R-devel from CRAN (e.g. in the  
tar.gzipped form to not have to worry about Apple's Installer  
upgrading the existing R) and archive only the packages. You can  
unpack them anywhere, just set R_LIBS or .libPaths() to the correct  
path.

I hope it helps. Let me know if you have questions about the details.

Cheers,
Simon
#
Following the point brought up by Vince Carey, I thought I'll share  
some info how you can create a version of R that is fully contained in  
the R.app bundle. i.e. all you have is just the "R" icon that can be  
moved/copied anywhere.

Prerequisities:
- Mac OS X 10.4 or higher
- Xcode developer tools installed (see R for Mac FAQ)
- somewhat recent, working R.app + R framework (e.g. from CRAN) in  
default locations

For simplicity I assume that you'll be assembling the R on your  
Desktop and you are using regular CRAN binary, but you can do that  
anywhere with any R.

copy/paste in Terminal (I hope your mailer doesn't wrap this):

cd ~/Desktop
# copy R.app
ditto /Applications/R.app R.app
cd R.app/Contents
# copy the R.framework inside
mkdir Frameworks
ditto /Library/Frameworks/R.framework R.framework

# fix all executables and libraries
for f in `find . \( -perm +a+x -a -type f \)`; do
if otool -L $f 2>/dev/null|grep Versions/.../Resources/lib >/dev/null  
2>&1; then
libs=`otool -L $f 2>/dev/null|sed -n 's:.*\(/Library/Frameworks/ 
R.framework/Versions.*\) (.*:\1:p'`
for lib in $libs; do
nlib=`echo $lib|sed 's:/Library/Frameworks/R.framework/ 
Versions/...:@executable_path/../Frameworks/R.framework:'`
echo $f:$lib
install_name_tool -change $lib $nlib $f
done
fi
done

Now you have a fully working R.app on your desktop that you can copy  
anywhere and it is self-contained. All paths are relative to the  
executable, hence relative to R.app.

[Note: in order to test the fact that it is relocatable, you have to  
move/rename/delete /Library/Frameworks/R.framework first, otherwise  
rogue packages might fall back to that]

CAVEAT: There is a caveat, though: you *cannot* install any packages  
with such R. Installing source package is a no-no (they won't compile)  
and installing binary packages will only work if you fix them before  
use (i.e. cd into R.app/Contents and re-run the script above starting  
with "for f...")
[Another caveat is that the command-line version of such R won't work,  
but that is expected, because the R start script contains hard-coded  
R_HOME path, so you'd have to fix that whenever you move R.app.]

Therefore you should install all necessary packages (in the system- 
wide location) *before* you package it.

This is indented for those who wish to carry R with them on a USB  
stick temporarily and/or give a specifically setup version of R to  
others (class/workshop ...). It is not intended for "regular" use and  
is not officially supported. Use at your own risk ;).

Hint: to create a compressed disk image of this R such that you can  
use it without installing, run
cd ~/Desktop
mkdir R
mv R.app R
hdiutil create -srcfolder R R.dmg

Cheers,
Simon

For advanced users: you can also use install_name_tool -id to change  
the IDs of libraries in $R_HOME/lib. If you do that to your system R,  
all compiled packages will be correctly linked so you don't need the  
fixup anymore.
1 day later
#
This is a very nice entry to the faq. Thanks Simon.

btw, wouldn't it be possible to create a small app (with an embedded  
script) to do this?
Which possibly makes a copy of R.app, so if you discover you need a  
additional package, you  install it in the original R.app and repackage.

stefano
p.s. I'm not volunteering though :)
On 08/mar/08, at 20:37, Simon Urbanek wrote: