declaring package dependencies

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

declaring package dependencies

Michael Friendly
I received the following email note re: the vcdExtra package

> A vcd update has shown that packages TIMP and vcdExtra are not
> declaring their dependence on colorspace/MASS: see
>
> http://cran.r-project.org/web/checks/check_results_vcdExtra.html
But, I can't see what to do to avoid this, nor understand what has
changed in R devel.

Sure enough, CRAN now reports errors in examples using MASS::loglm(),
using R Under development (unstable) (2013-09-11 r63906)

 > Caesar.mod0 <- loglm(~Infection + (Risk*Antibiotics*Planned),
data=Caesar)
Error: could not find function "loglm"

In DESCRIPTION I have
Depends: R (>= 2.10), vcd, gnm (>= 1.0.3)
Suggests:
ca,gmodels,Fahrmeir,effects,VGAM,plyr,rgl,lmtest,MASS,nnet,ggplot2,Sleuth2,car

and the vcd DESCRIPTION has

Depends: R (>= 2.4.0), grid, stats
Suggests: KernSmooth, mvtnorm, kernlab, HSAUR, coin
Imports: utils, MASS, grDevices, colorspace

so, in an R 3.0.0 console, library(vcdExtra) loads vcd and its dependencies:

 > library(vcdExtra)
Loading required package: vcd
Loading required package: MASS
Loading required package: grid
Loading required package: colorspace
Loading required package: gnm
Warning messages:
1: package ‘vcd’ was built under R version 3.0.1
2: package ‘MASS’ was built under R version 3.0.1
 >

Note: these CRAN errors do not occur on R-Forge, using R version 3.0.1
Patched (2013-08-21 r63645)
and the latest devel version (0.5-11) of vcdExtra.

-Michael

--
Michael Friendly     Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University      Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele Street    Web:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Paul Gilbert-2
Michael

(Several of us are struggling with these changes, so my comments are
from the newly initiated point of view, rather than the fully
knowledgeable.)

On 13-09-12 09:38 AM, Michael Friendly wrote:
> I received the following email note re: the vcdExtra package
>
>> A vcd update has shown that packages TIMP and vcdExtra are not
>> declaring their dependence on colorspace/MASS: see
>>
>> http://cran.r-project.org/web/checks/check_results_vcdExtra.html
> But, I can't see what to do to avoid this, nor understand what has
> changed in R devel.

Lots in this respect.

>
> Sure enough, CRAN now reports errors in examples using MASS::loglm(),
> using R Under development (unstable) (2013-09-11 r63906)
>
>  > Caesar.mod0 <- loglm(~Infection + (Risk*Antibiotics*Planned),
> data=Caesar)
> Error: could not find function "loglm"
>
> In DESCRIPTION I have
> Depends: R (>= 2.10), vcd, gnm (>= 1.0.3)

The "modern" way of thinking about this is that the Depends line should
not have much in it, only things from other packages that you want
directly available to the user. (There are a few other exceptions
necessary for packages that have not themselves embraced the "modern"
way.) Since you may want users of vcdExtra to automatically have access
to functions in vcd, without needing to execute library(vcd), this
classifies as one of the official exceptions and you probably want cvd
in the Depends line. However, chances are that gnm should be in
Imports:. If vcd is in the Depends line then it is automatically
attached and your examples do not need library(vcd) or requires(vcd).

The Note

   Unexported object imported by a ‘:::’ call: ‘vcd:::rootogram.default’

is harder to decide how to deal with. (This is sill just a note, but it
looks to me like a note that will soon become a warning or error.) The
simple solution is to export rootogram.default from vcd, but that
exposes it to all users, and really you may just want to expose it to
packages like vcdExtra. There was some recent discussion about this on
R-devel. I suggested one possibility would be some sort of limited
export. Since that was a suggestion that required work by someone else,
it probably went the same place as most of those suggestion do. The
solution I have adopted for the main case where this causes me problems
is to split the classes, generics, and methods into one package, and the
user functions into another. For example, if you have rootogram.default
in a package called vcdClasses and exported it, then both vcd and
vcdExtra can import it, but if it is not in their Depends line then it
will not be visible to a user that executes library(vcd) or
library(vcdExtra).

Beware that there is currently a small gotcha if the generics are S3,
which was discussed recently and a patch submitted by Henrik Bengtsson
(See Re: [Rd] "False" warning on "replacing previous import" when
re-exporting identical object .)


Although there has been much moaning about these changes, including my
own, I think the general logic is a real improvement. The way I think of
it, the namespace imports for a package provide the equivalent of a
search path for functions in the package, which is not changed by what
packages a user or other packages attach or import. Thus a package
developer has much more certain control over where the functions used by
the package will come from. This is a trade-off for safety rather than
convenience, thus the moaning. I am a complete newbie on this, but there
seems to be a pretty good unofficial description at
http://obeautifulcode.com/R/How-R-Searches-And-Finds-Stuff/.

> Suggests:
> ca,gmodels,Fahrmeir,effects,VGAM,plyr,rgl,lmtest,MASS,nnet,ggplot2,Sleuth2,car

If it is only in Suggests you can refer to it in the example by
MASS::loglm(), or require(MASS)/library(MASS). (I might have that wrong,
at least one works but I'm not certain of both.)
>
>
> and the vcd DESCRIPTION has
>
> Depends: R (>= 2.4.0), grid, stats
> Suggests: KernSmooth, mvtnorm, kernlab, HSAUR, coin
> Imports: utils, MASS, grDevices, colorspace

Probably grid and stats should be in Imports.

>
> so, in an R 3.0.0 console, library(vcdExtra) loads vcd and its
> dependencies:
>
>  > library(vcdExtra)
> Loading required package: vcd
> Loading required package: MASS
> Loading required package: grid
> Loading required package: colorspace
> Loading required package: gnm
> Warning messages:
> 1: package ‘vcd’ was built under R version 3.0.1
> 2: package ‘MASS’ was built under R version 3.0.1
>  >
>
> Note: these CRAN errors do not occur on R-Forge, using R version 3.0.1

Are you actually getting anything to build on R-forge? All my packages
have been stuck for a couple of weeks, as have many others.

Paul

> Patched (2013-08-21 r63645)
> and the latest devel version (0.5-11) of vcdExtra.
>
> -Michael
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Duncan Murdoch-2
In reply to this post by Michael Friendly
On 12/09/2013 9:38 AM, Michael Friendly wrote:

> I received the following email note re: the vcdExtra package
>
> > A vcd update has shown that packages TIMP and vcdExtra are not
> > declaring their dependence on colorspace/MASS: see
> >
> > http://cran.r-project.org/web/checks/check_results_vcdExtra.html
> But, I can't see what to do to avoid this, nor understand what has
> changed in R devel.
>
> Sure enough, CRAN now reports errors in examples using MASS::loglm(),
> using R Under development (unstable) (2013-09-11 r63906)
>
>   > Caesar.mod0 <- loglm(~Infection + (Risk*Antibiotics*Planned),
> data=Caesar)
> Error: could not find function "loglm"

I think this one would be fine if you had library(MASS) or require(MASS)
or (probably best) used MASS::loglm explicitly.  It may be that in the
past some other package put MASS on the search list, and that's why it
worked before.

The distinction is between "loading" and "attaching" a package. Loading
it (which would be done if you had MASS::loglm, or imported it)
guarantees that the package is initialized and in memory, but doesn't
make it visible to the user without the explicit MASS:: prefix.  
Attaching it first loads it, then modifies the user's search list so the
user can see it.

Loading is less intrusive, so it's preferred over attaching.  Both
library() and require() would attach it.

Duncan Murdoch

>
> In DESCRIPTION I have
> Depends: R (>= 2.10), vcd, gnm (>= 1.0.3)
> Suggests:
> ca,gmodels,Fahrmeir,effects,VGAM,plyr,rgl,lmtest,MASS,nnet,ggplot2,Sleuth2,car
>
> and the vcd DESCRIPTION has
>
> Depends: R (>= 2.4.0), grid, stats
> Suggests: KernSmooth, mvtnorm, kernlab, HSAUR, coin
> Imports: utils, MASS, grDevices, colorspace
>
> so, in an R 3.0.0 console, library(vcdExtra) loads vcd and its dependencies:
>
>   > library(vcdExtra)
> Loading required package: vcd
> Loading required package: MASS
> Loading required package: grid
> Loading required package: colorspace
> Loading required package: gnm
> Warning messages:
> 1: package ‘vcd’ was built under R version 3.0.1
> 2: package ‘MASS’ was built under R version 3.0.1
>   >
>
> Note: these CRAN errors do not occur on R-Forge, using R version 3.0.1
> Patched (2013-08-21 r63645)
> and the latest devel version (0.5-11) of vcdExtra.
>
> -Michael
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Michael Friendly
On 9/12/2013 1:37 PM, Duncan Murdoch wrote:

>
> I think this one would be fine if you had library(MASS) or
> require(MASS) or (probably best) used MASS::loglm explicitly.  It may
> be that in the past some other package put MASS on the search list,
> and that's why it worked before.
>
> The distinction is between "loading" and "attaching" a package.
> Loading it (which would be done if you had MASS::loglm, or imported
> it) guarantees that the package is initialized and in memory, but
> doesn't make it visible to the user without the explicit MASS::
> prefix.  Attaching it first loads it, then modifies the user's search
> list so the user can see it.
>
> Loading is less intrusive, so it's preferred over attaching.  Both
> library() and require() would attach it.
>
Thanks for this explanation, but I'm still confused about how to avoid
the wrath of the CRAN-devel
daemon, whose appetite for new morsels of developer flesh seems ever
increasing and makes
keeping even a stable package up-to-date a moving target.  Perhaps such
changes in R devel
should be announced on this list for public comment before they are
enforced in R CMD check.

In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
provide R code that
extends *.loglm methods.  All of this previously worked by including
Suggests: MASS, ...
Changing this to Imports: MASS seems rather heavy-handed; I don't really
want/need all of MASS
in my namespace, and using MASS::loglm in examples seems ugly.  For now,
I'll use
require(MASS) in each example.

> Attaching it first loads it, then modifies the user's search list so
> the user can see it.
Which directive does this?

--
Michael Friendly     Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University      Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele Street    Web:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Duncan Murdoch-2
On 13/09/2013 8:31 AM, Michael Friendly wrote:

> On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
> >
> > I think this one would be fine if you had library(MASS) or
> > require(MASS) or (probably best) used MASS::loglm explicitly.  It may
> > be that in the past some other package put MASS on the search list,
> > and that's why it worked before.
> >
> > The distinction is between "loading" and "attaching" a package.
> > Loading it (which would be done if you had MASS::loglm, or imported
> > it) guarantees that the package is initialized and in memory, but
> > doesn't make it visible to the user without the explicit MASS::
> > prefix.  Attaching it first loads it, then modifies the user's search
> > list so the user can see it.
> >
> > Loading is less intrusive, so it's preferred over attaching.  Both
> > library() and require() would attach it.
> >
> Thanks for this explanation, but I'm still confused about how to avoid
> the wrath of the CRAN-devel
> daemon, whose appetite for new morsels of developer flesh seems ever
> increasing and makes
> keeping even a stable package up-to-date a moving target.  Perhaps such
> changes in R devel
> should be announced on this list for public comment before they are
> enforced in R CMD check.
Changes are generally announced in the NEWS.Rd file long before release,
but R-devel is an unreleased version, so you won't see the news until it
is there.  Announcing things that nobody can try leads to fewer useful
comments than putting them into R-devel where at least people can see
what is really happening.

>
> In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
> provide R code that
> extends *.loglm methods.  All of this previously worked by including
> Suggests: MASS, ...
> Changing this to Imports: MASS seems rather heavy-handed; I don't really
> want/need all of MASS
> in my namespace, and using MASS::loglm in examples seems ugly.  For now,
> I'll use
> require(MASS) in each example.

If you need a small number of things from MASS in your package code,
then importing them explicitly is definitely the way to go, e.g.
importFrom(MASS, loglm).  If you only use them in examples, I wouldn't
do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
is ugly is a matter of taste:  it makes it clear to a user where that
function came from, and doesn't potentially hide objects from other
packages later in the search path.

On the other hand, require(pkg) is really simple; we have no equivalent
function that only does the loading, without attaching.
So it's hard to write

if (requireLoadable(MASS)) {
   MASS::loglm( ... )
}

>
> > Attaching it first loads it, then modifies the user's search list so
> > the user can see it.
> Which directive does this?

library() and require() both do it.

Duncan Murdoch
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Fortune! (Re: declaring package dependencies)

Dirk Eddelbuettel
In reply to this post by Michael Friendly

On 13 September 2013 at 08:31, Michael Friendly wrote:
| Thanks for this explanation, but I'm still confused about how to avoid
| the wrath of the CRAN-devel daemon, whose appetite for new morsels of
| developer flesh seems ever increasing and makes keeping even a stable
| package up-to-date a moving target.

_Obviously_ a fortunes candidate. CCing Achim.

[ And I informed my first-born that her time with us will surely be limited
  as I expect CRAN to demand every submitters first child any day now ... ]

| Perhaps such changes in R devel should be announced on this list for public
| comment before they are enforced in R CMD check.

Many of us have suggested that many times before, but CRAN has the longer
stick and simply refuses to play along.

"Eventually" the tides will turn and some of us will be fed up enough and
stop uploading.  But so far we still have an (uneasy?) truce, and everybody
is playing (fighting?) along.  

And don't even get me started on the state of r-forge build services...

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Dirk Eddelbuettel
In reply to this post by Duncan Murdoch-2

On 13 September 2013 at 09:51, Duncan Murdoch wrote:
| Changes are generally announced in the NEWS.Rd file long before release,
| but R-devel is an unreleased version, so you won't see the news until it
| is there.  Announcing things that nobody can try leads to fewer useful
| comments than putting them into R-devel where at least people can see
| what is really happening.

That comment makes sense _in theory_.

Yet _in practice_ it does not as many of us have been shot down by tests in
R-devel which had been implemented within a 48 hour window of the package
submission.

Absent a time machine or psychic powers, I do not see how package developers
can reasonably be expected to cope with this.

I am not close to Python, but the little I know about their PEP system makes
me think that a process in which changes are first announced as concepts,
then discussed and refined and only thereafter implemented seems somewhat
appealing.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Prof Brian Ripley
In reply to this post by Duncan Murdoch-2
On 13/09/2013 14:51, Duncan Murdoch wrote:

> On 13/09/2013 8:31 AM, Michael Friendly wrote:
>> On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
>> >
>> > I think this one would be fine if you had library(MASS) or
>> > require(MASS) or (probably best) used MASS::loglm explicitly.  It may
>> > be that in the past some other package put MASS on the search list,
>> > and that's why it worked before.
>> >
>> > The distinction is between "loading" and "attaching" a package.
>> > Loading it (which would be done if you had MASS::loglm, or imported
>> > it) guarantees that the package is initialized and in memory, but
>> > doesn't make it visible to the user without the explicit MASS::
>> > prefix.  Attaching it first loads it, then modifies the user's search
>> > list so the user can see it.
>> >
>> > Loading is less intrusive, so it's preferred over attaching.  Both
>> > library() and require() would attach it.
>> >
>> Thanks for this explanation, but I'm still confused about how to avoid
>> the wrath of the CRAN-devel
>> daemon, whose appetite for new morsels of developer flesh seems ever
>> increasing and makes
>> keeping even a stable package up-to-date a moving target.  Perhaps such
>> changes in R devel
>> should be announced on this list for public comment before they are
>> enforced in R CMD check.
> Changes are generally announced in the NEWS.Rd file long before release,
> but R-devel is an unreleased version, so you won't see the news until it
> is there.  Announcing things that nobody can try leads to fewer useful
> comments than putting them into R-devel where at least people can see
> what is really happening.
>>
>> In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
>> provide R code that
>> extends *.loglm methods.  All of this previously worked by including
>> Suggests: MASS, ...
>> Changing this to Imports: MASS seems rather heavy-handed; I don't really
>> want/need all of MASS
>> in my namespace, and using MASS::loglm in examples seems ugly.  For now,
>> I'll use
>> require(MASS) in each example.
>
> If you need a small number of things from MASS in your package code,
> then importing them explicitly is definitely the way to go, e.g.
> importFrom(MASS, loglm).  If you only use them in examples, I wouldn't
> do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
> is ugly is a matter of taste:  it makes it clear to a user where that
> function came from, and doesn't potentially hide objects from other
> packages later in the search path.
>
> On the other hand, require(pkg) is really simple; we have no equivalent
> function that only does the loading, without attaching.
> So it's hard to write
>
> if (requireLoadable(MASS)) {
>    MASS::loglm( ... )
> }

?requireNamespace.



>
>>
>> > Attaching it first loads it, then modifies the user's search list so
>> > the user can see it.
>> Which directive does this?
>
> library() and require() both do it.
>
> Duncan Murdoch
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Duncan Murdoch-2
In reply to this post by Dirk Eddelbuettel
On 13/09/2013 10:18 AM, Dirk Eddelbuettel wrote:

> On 13 September 2013 at 09:51, Duncan Murdoch wrote:
> | Changes are generally announced in the NEWS.Rd file long before release,
> | but R-devel is an unreleased version, so you won't see the news until it
> | is there.  Announcing things that nobody can try leads to fewer useful
> | comments than putting them into R-devel where at least people can see
> | what is really happening.
>
> That comment makes sense _in theory_.
>
> Yet _in practice_ it does not as many of us have been shot down by tests in
> R-devel which had been implemented within a 48 hour window of the package
> submission.

It sounds as though you are talking about CRAN here, not R.  I can't
speak for CRAN.

>
> Absent a time machine or psychic powers, I do not see how package developers
> can reasonably be expected to cope with this.

I'm a CRAN user as a package developer, and I do get emails about
changes, but I don't find them overwhelming, and I don't recall
receiving any that were irrational.  Generally the package is improved
when I follow their advice.  It has happened that I have been slower
than they liked in responding, but the world didn't end.

I imagine Rcpp pushes the limits more than my packages do, but I think
most developers can cope.  After all, the number of packages on CRAN is
increasing, not decreasing.

Duncan Murdoch

>
> I am not close to Python, but the little I know about their PEP system makes
> me think that a process in which changes are first announced as concepts,
> then discussed and refined and only thereafter implemented seems somewhat
> appealing.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Duncan Murdoch-2
In reply to this post by Prof Brian Ripley
On 13/09/2013 10:37 AM, Prof Brian Ripley wrote:

> On 13/09/2013 14:51, Duncan Murdoch wrote:
> > On 13/09/2013 8:31 AM, Michael Friendly wrote:
> >> On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
> >> >
> >> > I think this one would be fine if you had library(MASS) or
> >> > require(MASS) or (probably best) used MASS::loglm explicitly.  It may
> >> > be that in the past some other package put MASS on the search list,
> >> > and that's why it worked before.
> >> >
> >> > The distinction is between "loading" and "attaching" a package.
> >> > Loading it (which would be done if you had MASS::loglm, or imported
> >> > it) guarantees that the package is initialized and in memory, but
> >> > doesn't make it visible to the user without the explicit MASS::
> >> > prefix.  Attaching it first loads it, then modifies the user's search
> >> > list so the user can see it.
> >> >
> >> > Loading is less intrusive, so it's preferred over attaching.  Both
> >> > library() and require() would attach it.
> >> >
> >> Thanks for this explanation, but I'm still confused about how to avoid
> >> the wrath of the CRAN-devel
> >> daemon, whose appetite for new morsels of developer flesh seems ever
> >> increasing and makes
> >> keeping even a stable package up-to-date a moving target.  Perhaps such
> >> changes in R devel
> >> should be announced on this list for public comment before they are
> >> enforced in R CMD check.
> > Changes are generally announced in the NEWS.Rd file long before release,
> > but R-devel is an unreleased version, so you won't see the news until it
> > is there.  Announcing things that nobody can try leads to fewer useful
> > comments than putting them into R-devel where at least people can see
> > what is really happening.
> >>
> >> In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
> >> provide R code that
> >> extends *.loglm methods.  All of this previously worked by including
> >> Suggests: MASS, ...
> >> Changing this to Imports: MASS seems rather heavy-handed; I don't really
> >> want/need all of MASS
> >> in my namespace, and using MASS::loglm in examples seems ugly.  For now,
> >> I'll use
> >> require(MASS) in each example.
> >
> > If you need a small number of things from MASS in your package code,
> > then importing them explicitly is definitely the way to go, e.g.
> > importFrom(MASS, loglm).  If you only use them in examples, I wouldn't
> > do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
> > is ugly is a matter of taste:  it makes it clear to a user where that
> > function came from, and doesn't potentially hide objects from other
> > packages later in the search path.
> >
> > On the other hand, require(pkg) is really simple; we have no equivalent
> > function that only does the loading, without attaching.
> > So it's hard to write
> >
> > if (requireLoadable(MASS)) {
> >    MASS::loglm( ... )
> > }
>
> ?requireNamespace.

Thanks.  I'll switch my packages to use that.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Dirk Eddelbuettel
In reply to this post by Duncan Murdoch-2

On 13 September 2013 at 10:38, Duncan Murdoch wrote:
| On 13/09/2013 10:18 AM, Dirk Eddelbuettel wrote:
| > On 13 September 2013 at 09:51, Duncan Murdoch wrote:
| > | Changes are generally announced in the NEWS.Rd file long before release,
| > | but R-devel is an unreleased version, so you won't see the news until it
| > | is there.  Announcing things that nobody can try leads to fewer useful
| > | comments than putting them into R-devel where at least people can see
| > | what is really happening.
| >
| > That comment makes sense _in theory_.
| >
| > Yet _in practice_ it does not as many of us have been shot down by tests in
| > R-devel which had been implemented within a 48 hour window of the package
| > submission.
|
| It sounds as though you are talking about CRAN here, not R.  I can't
| speak for CRAN.

Hah :) -- in practive you actually do as the service you built to create RSS
summaries of R NEWS changes (ie R Core) is one good way to learn about CRAN
changes as the CRAN folks use the R Core access to R itself (via R CMD check)
to effect change.

And yes: we all want change for the better.

But we also want a more grown-up process.

| > Absent a time machine or psychic powers, I do not see how package developers
| > can reasonably be expected to cope with this.
|
| I'm a CRAN user as a package developer, and I do get emails about
| changes, but I don't find them overwhelming, and I don't recall
| receiving any that were irrational.  Generally the package is improved
| when I follow their advice.  It has happened that I have been slower
| than they liked in responding, but the world didn't end.

Of course they improve. The long arc of history points to progress. Packages
are better than they used to be (cf NAMESPACE discussion). Nobody disputes
that.

But what we take excpetion with is the _process_ and the matter in which
changes are (NOT REALLY) communicated, or even announced with a windows.
 
| I imagine Rcpp pushes the limits more than my packages do, but I think
| most developers can cope.  After all, the number of packages on CRAN is
| increasing, not decreasing.

It's not so much Rcpp itself or my 20-ish packages but the fact that we (as
in the Rcpp authors) now stand behind an API that also has to accomodate
changes in R CMD check. Case in point is current (unannounced) change that
makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks.

Yet I cannot really talk to 135 packages using Rcpp as I have CRAN Policy
document to point to.  

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Paul Gilbert-2


On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote:

>
> On 13 September 2013 at 10:38, Duncan Murdoch wrote:
> | On 13/09/2013 10:18 AM, Dirk Eddelbuettel wrote:
> | > On 13 September 2013 at 09:51, Duncan Murdoch wrote:
> | > | Changes are generally announced in the NEWS.Rd file long before release,
> | > | but R-devel is an unreleased version, so you won't see the news until it
> | > | is there.  Announcing things that nobody can try leads to fewer useful
> | > | comments than putting them into R-devel where at least people can see
> | > | what is really happening.
> | >
> | > That comment makes sense _in theory_.
> | >
> | > Yet _in practice_ it does not as many of us have been shot down by tests in
> | > R-devel which had been implemented within a 48 hour window of the package
> | > submission.
> |
> | It sounds as though you are talking about CRAN here, not R.  I can't
> | speak for CRAN.
>
> Hah :) -- in practive you actually do as the service you built to create RSS
> summaries of R NEWS changes (ie R Core) is one good way to learn about CRAN
> changes as the CRAN folks use the R Core access to R itself (via R CMD check)
> to effect change.
>
> And yes: we all want change for the better.
>
> But we also want a more grown-up process.
>
> | > Absent a time machine or psychic powers, I do not see how package developers
> | > can reasonably be expected to cope with this.
> |
> | I'm a CRAN user as a package developer, and I do get emails about
> | changes, but I don't find them overwhelming, and I don't recall
> | receiving any that were irrational.  Generally the package is improved
> | when I follow their advice.  It has happened that I have been slower
> | than they liked in responding, but the world didn't end.
>
> Of course they improve. The long arc of history points to progress. Packages
> are better than they used to be (cf NAMESPACE discussion). Nobody disputes
> that.
>
> But what we take excpetion with is the _process_ and the matter in which
> changes are (NOT REALLY) communicated, or even announced with a windows.
>
> | I imagine Rcpp pushes the limits more than my packages do, but I think
> | most developers can cope.  After all, the number of packages on CRAN is
> | increasing, not decreasing.
>
> It's not so much Rcpp itself or my 20-ish packages but the fact that we (as
> in the Rcpp authors) now stand behind an API that also has to accomodate
> changes in R CMD check. Case in point is current (unannounced) change that
> makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks.

I am a bit confused by this Dirk, so maybe I am missing something. I
think this is still a "Note" in R-devel so you do have some time to make
the change, at least several months, maybe more. It is not quite what I
think of as an "announcement", more like a shot across the bow, but it
is also not "unannounced".

More importantly, I don't think that the requirement is necessarily to
change Depends: Rcpp to Imports: Rcpp, the requirement is to put
imports(Rcpp) in the NAMESPACE file. I think this is so that the package
continues to work even if the user does something with the search path.
The decision to change Depends: Rcpp to Imports: Rcpp really depends on
whether the package author wants Rcpp functions to be available directly
by users without them needing to specifically attach Rcpp. They are
available with Depends but with Imports they are just used internally in
the package.

So, one of us is confused. Usually it is me.
Paul
>
> Yet I cannot really talk to 135 packages using Rcpp as I have CRAN Policy
> document to point to.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Dirk Eddelbuettel

On 13 September 2013 at 11:42, Paul Gilbert wrote:
| On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote:
| > It's not so much Rcpp itself or my 20-ish packages but the fact that we (as
| > in the Rcpp authors) now stand behind an API that also has to accomodate
| > changes in R CMD check. Case in point is current (unannounced) change that
| > makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks.
|
| I am a bit confused by this Dirk, so maybe I am missing something. I
| think this is still a "Note" in R-devel so you do have some time to make
| the change, at least several months, maybe more. It is not quite what I
| think of as an "announcement", more like a shot across the bow, but it
| is also not "unannounced".

One package author [as in user of Rcpp and not an author of it] was told by
CRAN this week to change his package and came to me for help -- so in that
small way the CRAN "non-communication policy" is already creating more work
for me, and makes me look silly as "I don't document what Rcpp-using packages
need" as I sadly still lack the time machine or psychic powers to infer what
may get changed this weekend.
 
| More importantly, I don't think that the requirement is necessarily to
| change Depends: Rcpp to Imports: Rcpp, the requirement is to put
| imports(Rcpp) in the NAMESPACE file. I think this is so that the package
| continues to work even if the user does something with the search path.
| The decision to change Depends: Rcpp to Imports: Rcpp really depends on
| whether the package author wants Rcpp functions to be available directly

Rcpp is a bit of an odd-ball as you mostly need it at compile-time, and you
require very few R-level functions (but there is package initialization etc
pp).  We also only about two handful of functions, and those are for
functionality not all 135 packages use (eg Modules etc).  

But the focus here should not be on my hobby package. The focus needs to be
on how four CRAN maintainers (who do a boatload of amazing work which is
_truly_ appreciated in its thoroughness and reach) could make the life of
authors of 4800+ packages easier by communicating and planning a tad more.

| by users without them needing to specifically attach Rcpp. They are
| available with Depends but with Imports they are just used internally in
| the package.
|
| So, one of us is confused. Usually it is me.

No, no, I usually keep you company.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Fox, John
In reply to this post by Duncan Murdoch-2
Dear Duncan and Michael,

> -----Original Message-----
> From: [hidden email] [mailto:r-devel-bounces@r-
> project.org] On Behalf Of Duncan Murdoch
> Sent: Friday, September 13, 2013 9:51 AM
> To: Michael Friendly
> Cc: r-devel
> Subject: Re: [Rd] declaring package dependencies
>
> On 13/09/2013 8:31 AM, Michael Friendly wrote:
> > On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
> > >
> > > I think this one would be fine if you had library(MASS) or
> > > require(MASS) or (probably best) used MASS::loglm explicitly.  It
> may
> > > be that in the past some other package put MASS on the search list,
> > > and that's why it worked before.
> > >
> > > The distinction is between "loading" and "attaching" a package.
> > > Loading it (which would be done if you had MASS::loglm, or imported
> > > it) guarantees that the package is initialized and in memory, but
> > > doesn't make it visible to the user without the explicit MASS::
> > > prefix.  Attaching it first loads it, then modifies the user's
> search
> > > list so the user can see it.
> > >
> > > Loading is less intrusive, so it's preferred over attaching.  Both
> > > library() and require() would attach it.
> > >
> > Thanks for this explanation, but I'm still confused about how to
> avoid
> > the wrath of the CRAN-devel
> > daemon, whose appetite for new morsels of developer flesh seems ever
> > increasing and makes
> > keeping even a stable package up-to-date a moving target.  Perhaps
> such
> > changes in R devel
> > should be announced on this list for public comment before they are
> > enforced in R CMD check.
> Changes are generally announced in the NEWS.Rd file long before
> release,
> but R-devel is an unreleased version, so you won't see the news until
> it
> is there.  Announcing things that nobody can try leads to fewer useful
> comments than putting them into R-devel where at least people can see
> what is really happening.
> >
> > In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and
> also
> > provide R code that
> > extends *.loglm methods.  All of this previously worked by including
> > Suggests: MASS, ...
> > Changing this to Imports: MASS seems rather heavy-handed; I don't
> really
> > want/need all of MASS
> > in my namespace, and using MASS::loglm in examples seems ugly.  For
> now,
> > I'll use
> > require(MASS) in each example.
>
> If you need a small number of things from MASS in your package code,
> then importing them explicitly is definitely the way to go, e.g.
> importFrom(MASS, loglm).  If you only use them in examples, I wouldn't
> do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
> is ugly is a matter of taste:  it makes it clear to a user where that
> function came from, and doesn't potentially hide objects from other
> packages later in the search path.
>

If I understand this thread, Michael's package doesn't use loglm() -- it
provides methods for objects produced by loglm() and hence "Enhances" the
package.

> On the other hand, require(pkg) is really simple; we have no equivalent
> function that only does the loading, without attaching.
> So it's hard to write
>
> if (requireLoadable(MASS)) {
>    MASS::loglm( ... )
> }
>

I understand why one would want to do this sort of thing (say, using
requireNamespace), to avoid attaching the MASS package to the search path
and possibly shadowing objects on the path, but I think that most users --
as opposed to R developers -- will find the package::function( ... ) syntax
in examples not so much ugly as cryptic. I think that we have ample recent
evidence on this list that even developers (I don't exempt myself) are
confused by namespace issues. On balance, I prefer

        if (require(MASS)) {
                loglm( ...)
        }

which tells the user that it's necessary to load MASS before using loglm().

It would be nice if examples ran in a "sandbox," so that an example could
read something like

        library(MASS)
        loglm( ... )
        . . .

without affecting the path in the current session, and fail gracefully if
the MASS package weren't available (unlikely, of course, in the case of
MASS, but not more generally).

Best,
 John

> >
> > > Attaching it first loads it, then modifies the user's search list
> so
> > > the user can see it.
> > Which directive does this?
>
> library() and require() both do it.
>
> Duncan Murdoch
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Gray
John Fox: (12:15PM on Fri, Sep 13)
[...cut...]

>I think that most users --
>as opposed to R developers -- will find the package::function( ... ) syntax
>in examples not so much ugly as cryptic. I think that we have ample recent
>evidence on this list that even developers (I don't exempt myself) are
>confused by namespace issues. On balance, I prefer
>
> if (require(MASS)) {
> loglm( ...)
> }
>
>which tells the user that it's necessary to load MASS before using loglm().
>
>It would be nice if examples ran in a "sandbox," so that an example could
>read something like
>
> library(MASS)
> loglm( ... )
> . . .
>
>without affecting the path in the current session, and fail gracefully if
>the MASS package weren't available (unlikely, of course, in the case of
>MASS, but not more generally).

Does assigning

     loglm <- MASS::loglm
     loglm( ... )

not work in examples anymore? (with MASS listed under 'Suggests'.)
That seems like it could address both concerns, but it would mask
loglm if it were already defined.

--
Gray Calhoun, Assistant Professor of Economics at Iowa State
http://gray.clhn.co // (515) 294-6271 // 467 Heady Hall

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fortune! (Re: declaring package dependencies)

Achim Zeileis-4
In reply to this post by Dirk Eddelbuettel
Thanks, added to the devel-version on R-Forge.
Z

On Fri, 13 Sep 2013, Dirk Eddelbuettel wrote:

>
> On 13 September 2013 at 08:31, Michael Friendly wrote:
> | Thanks for this explanation, but I'm still confused about how to avoid
> | the wrath of the CRAN-devel daemon, whose appetite for new morsels of
> | developer flesh seems ever increasing and makes keeping even a stable
> | package up-to-date a moving target.
>
> _Obviously_ a fortunes candidate. CCing Achim.
>
> [ And I informed my first-born that her time with us will surely be limited
>  as I expect CRAN to demand every submitters first child any day now ... ]
>
> | Perhaps such changes in R devel should be announced on this list for public
> | comment before they are enforced in R CMD check.
>
> Many of us have suggested that many times before, but CRAN has the longer
> stick and simply refuses to play along.
>
> "Eventually" the tides will turn and some of us will be fed up enough and
> stop uploading.  But so far we still have an (uneasy?) truce, and everybody
> is playing (fighting?) along.
>
> And don't even get me started on the state of r-forge build services...
>
> Dirk
>
> --
> Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Duncan Murdoch-2
In reply to this post by Dirk Eddelbuettel
On 13-09-13 12:00 PM, Dirk Eddelbuettel wrote:

>
> On 13 September 2013 at 11:42, Paul Gilbert wrote:
> | On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote:
> | > It's not so much Rcpp itself or my 20-ish packages but the fact that we (as
> | > in the Rcpp authors) now stand behind an API that also has to accomodate
> | > changes in R CMD check. Case in point is current (unannounced) change that
> | > makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks.
> |
> | I am a bit confused by this Dirk, so maybe I am missing something. I
> | think this is still a "Note" in R-devel so you do have some time to make
> | the change, at least several months, maybe more. It is not quite what I
> | think of as an "announcement", more like a shot across the bow, but it
> | is also not "unannounced".
>
> One package author [as in user of Rcpp and not an author of it] was told by
> CRAN this week to change his package and came to me for help -- so in that
> small way the CRAN "non-communication policy" is already creating more work
> for me, and makes me look silly as "I don't document what Rcpp-using packages
> need" as I sadly still lack the time machine or psychic powers to infer what
> may get changed this weekend.
>
> | More importantly, I don't think that the requirement is necessarily to
> | change Depends: Rcpp to Imports: Rcpp, the requirement is to put
> | imports(Rcpp) in the NAMESPACE file. I think this is so that the package
> | continues to work even if the user does something with the search path.
> | The decision to change Depends: Rcpp to Imports: Rcpp really depends on
> | whether the package author wants Rcpp functions to be available directly
>
> Rcpp is a bit of an odd-ball as you mostly need it at compile-time, and you
> require very few R-level functions (but there is package initialization etc
> pp).  We also only about two handful of functions, and those are for
> functionality not all 135 packages use (eg Modules etc).
>
> But the focus here should not be on my hobby package. The focus needs to be
> on how four CRAN maintainers (who do a boatload of amazing work which is
> _truly_ appreciated in its thoroughness and reach) could make the life of
> authors of 4800+ packages easier by communicating and planning a tad more.

Let me paraphrase that:  "The CRAN maintainers do a lot of work, and it
helps me a lot, but if they only did a little bit more work it would
help me even more."

I suspect they'd be more receptive to suggestions that had them doing
less work, not more.

Duncan Murdoch

>
> | by users without them needing to specifically attach Rcpp. They are
> | available with Depends but with Imports they are just used internally in
> | the package.
> |
> | So, one of us is confused. Usually it is me.
>
> No, no, I usually keep you company.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Dirk Eddelbuettel

On 14 September 2013 at 09:04, Duncan Murdoch wrote:
| On 13-09-13 12:00 PM, Dirk Eddelbuettel wrote:
| > But the focus here should not be on my hobby package. The focus needs to be
| > on how four CRAN maintainers (who do a boatload of amazing work which is
| > _truly_ appreciated in its thoroughness and reach) could make the life of
| > authors of 4800+ packages easier by communicating and planning a tad more.
|
| Let me paraphrase that:  "The CRAN maintainers do a lot of work, and it
| helps me a lot, but if they only did a little bit more work it would
| help me even more."
|
| I suspect they'd be more receptive to suggestions that had them doing
| less work, not more.

Presumably that also holds for the authors of the 4800+ packages.  

But my point is not the about "less", it is about "more predictable".
Currently, the system appears to be anything but.  We can do better.

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

braverock
In reply to this post by Duncan Murdoch-2
On 09/14/2013 08:04 AM, Duncan Murdoch wrote:
 >> On 13-09-13 12:00 PM, Dirk Eddelbuettel wrote:

>> But the focus here should not be on my hobby package. The focus
>> needs to be on how four CRAN maintainers (who do a boatload of
>> amazing work which is _truly_ appreciated in its thoroughness and
>> reach) could make the life of authors of 4800+ packages easier by
>> communicating and planning a tad more.
>
> Let me paraphrase that:  "The CRAN maintainers do a lot of work, and it
> helps me a lot, but if they only did a little bit more work it would
> help me even more."
>
> I suspect they'd be more receptive to suggestions that had them doing
> less work, not more.

I think you're both right.

If the CRAN team would communicate more with this list about pending
changes, package authors could make those changes before submitting.
Those submissions that won't pass unannounced R-devel checks waste
everybody's time, including the time of the CRAN team.

Not to mention, most open source projects seem to have concluded that
more eyes on pending or proposed changes make everyone's life better in
the long term.

Regards,

Brian

--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: declaring package dependencies

Paul Gilbert-2
In reply to this post by Duncan Murdoch-2


On 13-09-14 09:04 AM, Duncan Murdoch wrote:

> On 13-09-13 12:00 PM, Dirk Eddelbuettel wrote:
>>
>> On 13 September 2013 at 11:42, Paul Gilbert wrote:
>> | On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote:
>> | > It's not so much Rcpp itself or my 20-ish packages but the fact
>> that we (as
>> | > in the Rcpp authors) now stand behind an API that also has to
>> accomodate
>> | > changes in R CMD check. Case in point is current (unannounced)
>> change that
>> | > makes all Depends: Rcpp become Imports: Rcpp because of the
>> NAMESPACE checks.
>> |
>> | I am a bit confused by this Dirk, so maybe I am missing something. I
>> | think this is still a "Note" in R-devel so you do have some time to
>> make
>> | the change, at least several months, maybe more. It is not quite what I
>> | think of as an "announcement", more like a shot across the bow, but it
>> | is also not "unannounced".
>>
>> One package author [as in user of Rcpp and not an author of it] was
>> told by
>> CRAN this week to change his package and came to me for help -- so in
>> that
>> small way the CRAN "non-communication policy" is already creating more
>> work
>> for me, and makes me look silly as "I don't document what Rcpp-using
>> packages
>> need" as I sadly still lack the time machine or psychic powers to
>> infer what
>> may get changed this weekend.
>>
>> | More importantly, I don't think that the requirement is necessarily to
>> | change Depends: Rcpp to Imports: Rcpp, the requirement is to put
>> | imports(Rcpp) in the NAMESPACE file. I think this is so that the
>> package
>> | continues to work even if the user does something with the search path.
>> | The decision to change Depends: Rcpp to Imports: Rcpp really depends on
>> | whether the package author wants Rcpp functions to be available
>> directly
>>
>> Rcpp is a bit of an odd-ball as you mostly need it at compile-time,
>> and you
>> require very few R-level functions (but there is package
>> initialization etc
>> pp).  We also only about two handful of functions, and those are for
>> functionality not all 135 packages use (eg Modules etc).
>>
>> But the focus here should not be on my hobby package. The focus needs
>> to be
>> on how four CRAN maintainers (who do a boatload of amazing work which is
>> _truly_ appreciated in its thoroughness and reach) could make the life of
>> authors of 4800+ packages easier by communicating and planning a tad
>> more.
>
> Let me paraphrase that:  "The CRAN maintainers do a lot of work, and it
> helps me a lot, but if they only did a little bit more work it would
> help me even more."
>
> I suspect they'd be more receptive to suggestions that had them doing
> less work, not more.

Actually, this is one of the parts that I do not understand. It seems to
me that it would be a lot less work for CRAN maintainers if the
implications and necessary changes to packages were explained a bit more
clearly in a forum like R-devel that many package developers actually
read regularly. I many not fully understand how much of the response to
package submission gets done automatically, but I do get the sense that
there is a fairly large amount of actual human time spent dealing with
just my submissions alone. If that is representative of all developers,
then CRAN maintainers don't have time to do much else. (The fact that
they do much more suggests I may not be representative.)

Two specific points have already been mentioned implicitly. CRAN
submission testing is often done at a higher/newer level using the
latest devel version. This results in lots of rejections for things that
I would fix before submission, if I knew about them. If the tests were
rolled out with R, and only later incorporated into CRAN submission
testing, I think there would be a lot less work for the CRAN
maintainers. (This is ignoring the possibility that CRAN submission is
really the testing ground for the tests, and to prove the tests requires
a fair amount of manual involvement. I'm happy to continue contributing
to this -- I've often felt my many contribution is an endless supply of
bugs for the checkers to catch.)

The second point is that a facility like R-forge that runs the latest
checks, on many platforms, is really useful in order to reduce work for
both package developers and CRAN maintainers. With R-forge broken, the
implication for additional work for CRAN maintainers seems enormous. But
even with it working, not all packages are kept on R-forge, and with
package version dependencies R-forge does not really work. (i.e. I have
to get new versions of some packages onto CRAN before the new versions
of other packages will build on R-forge.)  Perhaps the package checking
part of R-forge should be separated into a pre-submission clearing house
to which packages are submitted. If they pass checks there then the
package developer could click on a submit button to do the actual
submission to CRAN. (Of course there needs to be a mechanism to plead
for the fact that the test systems do not have needed resources.)
Something like the daily, but with new pre-release versions of packages
might actually be better than the R-forge approach, for two reasons. One
is that package maintainers would only put packages there that they
think are actually working. (R-forge tries to build my svn copy even
when I know it is broken.) The second is that it would automatically
handle the version dependency problem, since package maintainers would
have the ability to put in place versions that should work together.
However, this does not need to be run daily. It only needs to be run
when the checks change, or for a package when the package changes.

Paul

>
> Duncan Murdoch
>
>>
>> | by users without them needing to specifically attach Rcpp. They are
>> | available with Depends but with Imports they are just used
>> internally in
>> | the package.
>> |
>> | So, one of us is confused. Usually it is me.
>>
>> No, no, I usually keep you company.
>>
>> Dirk
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
123