Re: [Rd] How graphical an interface should the default be?

From: Prof Brian Ripley <>
Date: Fri 25 Feb 2005 - 23:09:48 EST

On Fri, 25 Feb 2005, Robert Gentleman wrote:

> On Feb 25, 2005, at 3:11 AM, Prof Brian Ripley wrote:
>> install/update.packages will have a lot of changes in 2.1.0, and I have
>> been adding some widgets to go along with this.
>> - Rather than just CRAN and BIOC, you have a character vector of
>> repositories. There is a function setRepositories() to set the
>> appropriate option().
>> - There is no default CRAN, but a function chooseCRANmirror() to set a
>> mirror, which is invoked if you try to access CRAN without setting a
>> mirror.
>> - update.packages(ask="graphics") brings up a listbox for you to de-select
>> packages (all available updates are pre-selected).
>> - install.packages() with no/empty pkgs argument brings up a listbox of
>> all available packages (including those inside bundles).
>> - menu(graphics=TRUE) is implemented.
>> These can be set up to use widgets where available (Windows, if Tk is
>> available under X11, I hope Aqua before release), and have a text-mode
>> fallback (better than the current menu(), but in that spirit). (Except that
>> is install.packages: text-mode selection from 480 packages even in three
>> columns is not useful to me, but a scrolling list works well as Windows
>> users of R already know.)
>> My question is:
>> What should be default be?
>> Options might be:
>> - use the graphics widget if available.
>> - make the graphics the default on Windows (it will always be available,
>> but not necessarily on the right screen under DCOM uses).
>> - make text-mode the default on Unix.

>> - do different things for different tools. Currently setRepositories()
>> and chooseCRANmirror() default to graphics-if-possible, and
>> update.packages() defaults to text mode (which gives more

>> detailed information).
>> I am not really in favour of making the defaults a set of options, but that
>> is possible.
>> This is a request for input on what would be a good compromise for general
>> R users (and not just the R-devel audience).
> Hi,
> Thanks for taking this on - it looks like a big step forward. I have some
> pretty minor comments/questions. We will, of course, try to adapt the BioC
> code in time...
> We probably want to be sure that any function calling one of these has
> complete control and can override user defined defaults.

They have arguments to control this, e.g.

> args(chooseCRANmirror)

function (graphics = TRUE)

> I am not completely clear on your model for how the repositories are
> searched though. Two questions come to mind: 1) How do I get the most recent
> version of a package, regardless of which repository it is in?

That is the documented default behaviour. (`Most recent' = `highest version number'.) If more than one repository offers the same version, it is taken from the first on the list.

Icens is the only example that I have noticed, where BioC has a later version than CRAN.

setRepositories allows users to choose the order only in the text version, and you can of course just set the option from the command-line.

> 2) Can a package from one repository have its dependencies resolved in
> another repository, or not?

Yes, but looking for dependencies is not the default, so you can do something like

install.packages("foo", repos="",dependencies=TRUE)

to confine the search.

> (this last one is a real can of worms - in my view, as one might really
> prefer a same repository solution, but that means that repositories
> might need to completely contain CRAN - which is clearly less
> desirable). And of course this may be too fine a level of detail, but
> these problems have come up in our experience.
> I think it would be nice if getting dependencies had two (or more
> levels), so that I could get only those packages that the current
> package "Depends" on, and a second level where I could get both the
> "Suggests" and the "Depends". For me (at least) Suggests is weaker, and
> for many users the "Suggests" set of packages is not always needed - the
> "Depends" set, is though. Currently the dependencies option seems to
> only allow TRUE and FALSE.

That's true as for 2.0.0, and we could easily refine it (you need Imports too).


Brian D. Ripley,        
Professor of Applied Statistics,
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________ mailing list
Received on Fri Feb 25 23:23:00 2005

This archive was generated by hypermail 2.1.8 : Fri 25 Feb 2005 - 23:33:25 EST