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

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
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="http://www.bioconductor.org",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

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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