Skip to content

Clarification of R-Tcl/Tk installation wish-list

8 messages · James Wettenhall, stefano iacus, Simon Urbanek

#
Hi,

I just thought I'd clarfify my "wish-list" for R-Tcl/Tk 
installation on Mac OS X.

If R-Tcl/Tk could be installed without the developer tools, 
the number of Mac-users of my GUIs would more than double! 
Installing Tcl/Tk from source may seem easy enough to Unix 
command-line users, but to my GUI users (biologists), they 
generally don't have the developer tools, and if anything 
went wrong with installing Tcl/Tk from source (e.g. X11 
headers and libraries not found), then they would give up 
very quickly.  Mac-using biologists don't necessarily have 
a Unix-minded I.T. administrator.

Does anyone else like the idea of having an option of installing 
Tcl/Tk binaries in $R_HOME/Tcl/ in the same way that it is done 
on Windows?  See "R_Tcl.zip" on Duncan Murdoch's webpage:
http://www.murdoch-sutherland.com/Rtools/

Now, as far as adminstrator privileges, it looks like I still 
have a bit to learn about the difference between root and 
administrator on Mac OS X.  But my desire should be clear - to 
be able to double-click the R installer from R.dmg and install 
it in a custom directory (without getting an error message 
saying that it requires administrator privileges).  Then I could 
practise building and installing my own customized R installer.

Maybe non-administrator installation in a custom directory is 
more difficult on Mac OS X than on Windows, because Mac OS X is 
based on Unix where it is natural to choose the --prefix for 
configure BEFORE building from source (so the binaries may 
contain absolute directory paths).  Similarly, some RPMs on 
Linux can only be installed in one place.  Can Mac OS X be 
more flexible, like R for Windows?

I wish I could sound more experienced with installing R on Mac, 
but we have a strict I.T. department which won't let me install 
anything requiring admin or root privileges.

Best regards,
James
#
On Jul 7, 2004, at 2:15 AM, James Wettenhall wrote:

            
It can always be installed w/o developer tools. If you're worried about 
add-ons then I'd rather worry about X11 which isn't installed by 
default ;).
Well, it's one way to go ... I guess the problem is that there is not 
just one Tck/Tk for OS X. The native versions come as frameworks which 
makes sense. Supplying X11 versions as frameworks is questionable, but 
possible. Since the X11 versions are not really Mac-native, they 
probably shouldn't "shadow" the native way (frameworks)... I guess some 
people think they should go to /usr/local/...
root - user with all privileges - this one is by default disabled in OS 
X (i.e. you can't directly login as root)
admin - an user belonging to the "admin" group which is used throughout 
the system (e.g. you can write in Applications) also can use sudo to 
run commands in the root context
There's no error message :P Anyway, but "custom directory" is a 
problem. Not from the installer point of view - you can install 
anything anywhere, but R is not easily relocatable. The only way to 
relocate R is to patch all binaries and modify dynamic references. It 
can be done, but is tedious and error-prone. This is why we have the 
fixed framework and relocatable R.app.
It's not really a question of the operating system being more flexible 
or not. It's the way things are linked, built and installed. IMHO the 
building process could be slightly modified to allow relocatable R 
framework (don't use paths in linked objects and rely on LIBRARY_PATH). 
However there are some issues with add-ons such as newly compiled 
packages. The main problem is that we would need to kind of `bypass' 
the framework concept and use our own concept that requires several 
preparations before R or libR can be used (setting correct LP etc.) -  
and that's what we wanted to prevent. Moreover you could create 
inconsistencies when libraries are loaded from somewhere else that 
you'd expect (which can happen on Windows).

Again, a compromise would be to fix all paths on install ...

But back to your issue: why would you want to insist on re-locatable 
framework? One way of achieving what you want would be to use one of 
the regular places like Applications or Users/Shared - at least I guess 
that should work for your biologists and you wouldn't have to think 
about OS X internals... Moreover if you want to deal with Tcl/Tk you 
ran into relocation issues, too.

Simon
#
Simon,

Thanks very much for your reply.

To further clarify one thing, the relocatable R installation 
issue is certainly not important for the end user, but is more 
an issue for me in practising building and installing a 
customized wizard without having sufficient installation 
privileges.  I have had great success doing this on Windows, 
without ever being able to write to the Windows Registry (for 
LOCAL_MACHINE, only CURRENT_USER), and without being able to 
write to C:\Program Files\ or C:\WINNT.  

I do understand the multiple Tcl/Tk issue for MacOS X.  My 
impression is that Aqua Tcl/Tk has the nicest binary 
installation wizards at the moment (which is natural because it 
is 'native'), but for now, X11 seems to work more reliably with 
R, which is why I was thinking of an X11 binary Tcl/Tk bundled 
with R for Mac in the way binary Tcl/Tk is bundled with R for 
Windows.  (Then I'd be quite happy for it to be replaced by 
Aqua Tcl/Tk in the future.)  But I'll read over your email 
again, and give it some more thought.

Regards,
James
#
Hi James,

just for you convenience, I've add a package installer for the X11 
TclTk libraries.
It still require privileges though.

I think it is reasonable to distribute tcltk inside the framework, but 
it's not just a matter of dlls path in this case as the dll are there 
(inside the R.framework) with the correct paths (the problem is in that 
I did not patch the tcltk package to take the good tcl.ini and tk.ini 
files).

stefano
On Jul 7, 2004, at 12:50 PM, James Wettenhall wrote:

            
#
On Jul 7, 2004, at 11:54 AM, Simon Urbanek wrote:

            
the R.framework per se is relocatable, the problem is that moving the 
R.framework outside "standard" locations, i.e. where the linker and 
apps expect they to be, make every additional binary distibuted package 
to fail and even building of packages to fail.
The same applies to apps  embedding R.

I don't think that bypass the framework is a good idea as it is the way 
apple thinks about its system.

But relocation is not what I understand you are saying James. R.app is 
relocatable in the sense you can move it at any time on your system. A 
framework (any) once installed, to be moved requires  many things 
(related to the path) to be fixed.
We can certainly prepare a script to do the task, but this is not the 
way you do things on Macs
what you can reasonably do James, is to ask your system manager to 
install the tcltk stuff and the developer tools (how can you build your 
packages without?).
Packages will be built in your local directory ~/Library/R/library, 
tar.gz the binaries and distribute them. They will work.

stefano
#
Hi Stefano,
On Wed, 7 Jul 2004, stefano iacus wrote:
(at http://www.economia.unimi.it/R/)

Thanks very much!  I really appreciate it!

Regards,
James
#
Hi Stefano,
On Wed, 7 Jul 2004, stefano iacus wrote:
My GUI packages are just R packages with no compiled code.  They
just use the tcltk package, e.g. tt<-tktoplevel() etc.  I don't
have a Mac in my office, so I like to build a Win32 binary .zip
version and a .tar.gz source version of each R package from
Windows.  Then I would hope that R on MacOSX could install a
.tar.gz "source" R package without developer tools (given that
there's only R code, no compiled C or Fortran code).  Of
course, I've noticed on CRAN, that Mac OS X binary versions of
R packages are starting to appear, so maybe I should do that as
well.  But for now I'm just trying to learn a nice way to
install my R packages (requiring the standard tcltk + Tktable
and BWidget) for Mac users without the developer tools.

On Windows, there's no multiple Tcl/Tk issue, so my R package's
.First.lib() looks in the Windows registry for ActiveTcl (the
standard Tcl/Tk distribution for Windows) and automatically
runs addTclPath() from within R so that Tktable and BWidget can
be found and gives a warning if ActiveTcl is not found.   But
I still allow a custom Tcl/Tk installation), e.g. the user can
run addTclPath() themself from R or they can set environment
variables TCL_LIBRARY="C:\Tcl\lib" and MY_TCLTK="Yes".

Maybe I can eventually do something similar (to what I do
with ActiveTcl) with TclTkAquaBI.

Best regards,
James
#
On Jul 7, 2004, at 6:36 PM, stefano iacus wrote:

            
currently (as-is 1.9.1) it's not as I explained to James (I should've 
CC it here I guess) - R.bin and libR.dylib are both linked to readline 
using full path to the R home. There are several other minor issues 
like newly compiled packages containing absolute paths etc.
/me nods
@James: note that if you create your own, relocatable version of R you 
will have to check whether the CRAN packages work with it. If they 
won't then you're definitely in trouble, because installing packages is 
what most people need in the first place.
Again, they will only work if at least the following is satisfied
1) they are relocatable - because every user's home is in a different 
path (and ~ is only a shell construct, not a valid path)
2) before loading the libraries some script will find the proper 
libraries and setup the environment correspondingly

However I still think that the best way is to use regular R 
installation in /Library/Frameworks ... it's supported, transparent and 
extensible. As I said before, installing X11 requires co-operation of 
the admin anyway, so he can as well install R, too.

Cheers,
Simon

---
Simon Urbanek
Department of computer oriented statistics and data analysis
University of Augsburg
Universit?tsstr. 14
86135 Augsburg
Germany

Tel: +49-821-598-2236
Fax: +49-821-598-2200

Simon.Urbanek@Math.Uni-Augsburg.de
http://simon.urbanek.info