optional package dependency

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

optional package dependency

Ross Boylan
I have a package that can use rmpi, but works fine without it.  None of
the automatic test code invokes rmpi functionality.  (One test file
illustrates how to use it, but has quit() as its first command.)

What's the best way to handle this?  In particular, what is the
appropriate form for upload to CRAN?

When I omitted rmpi from the DESCRITPION file R CMD check gave
<quote>
* checking R code for possible problems ... NOTE
alldone: no visible global function definition for ‘mpi.bcast.Robj’
alldone: no visible global function definition for ‘mpi.exit’
<quote>
followed by many more warnings.

When I add
Suggests: Rmpi
in DESCRIPTION the check stops if the package is not installed:
<quote>
* checking package dependencies ... ERROR
Packages required but not available:
  Rmpi
</quote>
Rmpi is not required, but I gather from previous discussion on this list
that suggests basically means required for R CMD check.

NAMESPACE seems to raise similar issues; I don't see any mechanism for
optional imports.  Also, I have not used namespaces, and am not eager to
destabilize things so close to release.  At least, I hope I'm close to
release :)

Thanks for any advice.

Ross Boylan

P.S. Thanks, Duncan, for your recent advice on my help format problem
with R 2.7.  I removed the nested \description, and now things look OK.

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

Re: optional package dependency

Jeffrey Ryan
Hi Ross,

The quantmod package makes available routines from a variety of
contributed packages, but gets around your issues with a bit of, um,
trickery.

Take a look here (unless your name is Kurt ;-) ):

http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367&root=quantmod&view=markup

It would be nice to have Suggests really mean suggests to check, but I
am sure there is a good reason it doesn't.

HTH
Jeff

On Fri, Jan 15, 2010 at 12:00 AM, Ross Boylan <[hidden email]> wrote:

> I have a package that can use rmpi, but works fine without it.  None of
> the automatic test code invokes rmpi functionality.  (One test file
> illustrates how to use it, but has quit() as its first command.)
>
> What's the best way to handle this?  In particular, what is the
> appropriate form for upload to CRAN?
>
> When I omitted rmpi from the DESCRITPION file R CMD check gave
> <quote>
> * checking R code for possible problems ... NOTE
> alldone: no visible global function definition for ‘mpi.bcast.Robj’
> alldone: no visible global function definition for ‘mpi.exit’
> <quote>
> followed by many more warnings.
>
> When I add
> Suggests: Rmpi
> in DESCRIPTION the check stops if the package is not installed:
> <quote>
> * checking package dependencies ... ERROR
> Packages required but not available:
>  Rmpi
> </quote>
> Rmpi is not required, but I gather from previous discussion on this list
> that suggests basically means required for R CMD check.
>
> NAMESPACE seems to raise similar issues; I don't see any mechanism for
> optional imports.  Also, I have not used namespaces, and am not eager to
> destabilize things so close to release.  At least, I hope I'm close to
> release :)
>
> Thanks for any advice.
>
> Ross Boylan
>
> P.S. Thanks, Duncan, for your recent advice on my help format problem
> with R 2.7.  I removed the nested \description, and now things look OK.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



--
Jeffrey Ryan
[hidden email]

ia: insight algorithmics
www.insightalgo.com

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

Re: optional package dependency

Jari Oksanen
On Fri, 2010-01-15 at 00:12 -0600, Jeff Ryan wrote:

> Hi Ross,
>
> The quantmod package makes available routines from a variety of
> contributed packages, but gets around your issues with a bit of, um,
> trickery.
>
> Take a look here (unless your name is Kurt ;-) ):
>
> http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367&root=quantmod&view=markup
>
> It would be nice to have Suggests really mean suggests to check, but I
> am sure there is a good reason it doesn't.
>
I agree: it would be nice to have "Suggests" really mean "suggests", and
I 'suggested' so in an R-devel message of 20/9/05 with subject "Shy
Suggestion" (but this seems not exist in the R-devel archive?). I got
some support, but not from the right people, and so the R suggestion
remains the one you can't refuse or you'll wake up with a horse head in
your bed. I can live with this forced suggestion, although it is
sometimes painful, in particular in Mac or after re-installing
everything from scratch in Linux.

The main argument was that building may fail later if you don't check
"suggests" early so that you must (de facto) depend on packages you
suggest. I'm sure many packages would fail now if the interpretation of
"suggests" was changed because the behaviour of "suggests" and "depends"
has been near identical for a long time and people have adapted. The
window of opportunity for another interpretation was when the checks for
undefined request() was added to the R CMD check routines in 2005, but
then it was decided that "suggests" should be near equivalent to
"depends", and this will stick.

Cheers, Jari Oksanen

--
Jari Oksanen, Department of Biology, Univ Oulu, FI-90014 Oulu, Finland
http://www.oulu.fi/~jarioksa http://vegan.r-forge.r-project.org

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

Re: optional package dependency

Kurt Hornik-5
In reply to this post by Jeffrey Ryan
>>>>> Jeff Ryan writes:

> Hi Ross,
> The quantmod package makes available routines from a variety of
> contributed packages, but gets around your issues with a bit of, um,
> trickery.

> Take a look here (unless your name is Kurt ;-) ):

But Kurt will we happy to tell you that you can turn off "forcing"
suggested packages for checking by setting

  _R_CHECK_FORCE_SUGGESTS_=false

in your environment.  The idea is that maintainers typically want to
fully check their functionality, suggesting to force suggests by
default.

-k
 

> http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367&root=quantmod&view=markup

> It would be nice to have Suggests really mean suggests to check, but I
> am sure there is a good reason it doesn't.

> HTH
> Jeff

> On Fri, Jan 15, 2010 at 12:00 AM, Ross Boylan <[hidden email]> wrote:
>> I have a package that can use rmpi, but works fine without it.  None of
>> the automatic test code invokes rmpi functionality.  (One test file
>> illustrates how to use it, but has quit() as its first command.)
>>
>> What's the best way to handle this?  In particular, what is the
>> appropriate form for upload to CRAN?
>>
>> When I omitted rmpi from the DESCRITPION file R CMD check gave
>> <quote>
>> * checking R code for possible problems ... NOTE
>> alldone: no visible global function definition for ‘mpi.bcast.Robj’
>> alldone: no visible global function definition for ‘mpi.exit’
>> <quote>
>> followed by many more warnings.
>>
>> When I add
>> Suggests: Rmpi
>> in DESCRIPTION the check stops if the package is not installed:
>> <quote>
>> * checking package dependencies ... ERROR
>> Packages required but not available:
>>  Rmpi
>> </quote>
>> Rmpi is not required, but I gather from previous discussion on this list
>> that suggests basically means required for R CMD check.
>>
>> NAMESPACE seems to raise similar issues; I don't see any mechanism for
>> optional imports.  Also, I have not used namespaces, and am not eager to
>> destabilize things so close to release.  At least, I hope I'm close to
>> release :)
>>
>> Thanks for any advice.
>>
>> Ross Boylan
>>
>> P.S. Thanks, Duncan, for your recent advice on my help format problem
>> with R 2.7.  I removed the nested \description, and now things look OK.
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>



> --
> Jeffrey Ryan
> [hidden email]

> ia: insight algorithmics
> www.insightalgo.com

> ______________________________________________
> [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: optional package dependency

Benilton Carvalho-2
In reply to this post by Ross Boylan
How about using:

Enhances: Rmpi

?

b

On Fri, Jan 15, 2010 at 6:00 AM, Ross Boylan <[hidden email]> wrote:

> I have a package that can use rmpi, but works fine without it.  None of
> the automatic test code invokes rmpi functionality.  (One test file
> illustrates how to use it, but has quit() as its first command.)
>
> What's the best way to handle this?  In particular, what is the
> appropriate form for upload to CRAN?
>
> When I omitted rmpi from the DESCRITPION file R CMD check gave
> <quote>
> * checking R code for possible problems ... NOTE
> alldone: no visible global function definition for ‘mpi.bcast.Robj’
> alldone: no visible global function definition for ‘mpi.exit’
> <quote>
> followed by many more warnings.
>
> When I add
> Suggests: Rmpi
> in DESCRIPTION the check stops if the package is not installed:
> <quote>
> * checking package dependencies ... ERROR
> Packages required but not available:
>  Rmpi
> </quote>
> Rmpi is not required, but I gather from previous discussion on this list
> that suggests basically means required for R CMD check.
>
> NAMESPACE seems to raise similar issues; I don't see any mechanism for
> optional imports.  Also, I have not used namespaces, and am not eager to
> destabilize things so close to release.  At least, I hope I'm close to
> release :)
>
> Thanks for any advice.
>
> Ross Boylan
>
> P.S. Thanks, Duncan, for your recent advice on my help format problem
> with R 2.7.  I removed the nested \description, and now things look OK.
>
> ______________________________________________
> [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: optional package dependency

Seth Falcon-3
In reply to this post by Kurt Hornik-5
On 1/15/10 12:19 AM, Kurt Hornik wrote:
>>>>>> Jeff Ryan writes:
>
>> Hi Ross,
>> The quantmod package makes available routines from a variety of
>> contributed packages, but gets around your issues with a bit of, um,
>> trickery.
>
>> Take a look here (unless your name is Kurt ;-) ):

I believe another option is:

   pkg <- "somePkg"
   pkgAvail <- require(pkg, character.only = TRUE)
   if (pkgAvail)
      ...
   else
      ...


> But Kurt will we happy to tell you that you can turn off "forcing"
> suggested packages for checking by setting
>
>   _R_CHECK_FORCE_SUGGESTS_=false
>
> in your environment.  The idea is that maintainers typically want to
> fully check their functionality, suggesting to force suggests by
> default.

Unless the public repositories such as CRAN and Bioconductor decide to
set this option, it provides no solution for anyone who maintains or
plans to make available a package through a public R repository such as
CRAN or Bioconductor.

There is a real need (of some kind) here.  Not all packages work on all
platforms.  For example, the multicore package provides a mechanism for
running parallel computations on a multi-cpu box, but it is not
available on Windows.  A package that _is_ available on all platforms
should be able to optionally make use of multicore on non-Windows.  I
don't think there is a way to do that now and pass check without
resorting to "tricks" as above.  These tricks are bad as they make it
harder to programmatically determine the true "suggests".

And NAMESPACE brings up another issue in that being able to do
conditional imports would be very useful for these cases, otherwise you
simply can't make proper use of name spaces for any optional functionality.

I'm willing to help work on and test a solution if we can arrive at some
consensus as to what the solution looks like.

Best,

+ seth

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

Re: optional package dependency

Simon Urbanek

On Jan 15, 2010, at 10:22 , Seth Falcon wrote:

> On 1/15/10 12:19 AM, Kurt Hornik wrote:
>>>>>>> Jeff Ryan writes:
>>
>>> Hi Ross,
>>> The quantmod package makes available routines from a variety of
>>> contributed packages, but gets around your issues with a bit of, um,
>>> trickery.
>>
>>> Take a look here (unless your name is Kurt ;-) ):
>
> I believe another option is:
>
>   pkg <- "somePkg"
>   pkgAvail <- require(pkg, character.only = TRUE)
>   if (pkgAvail)
>      ...
>   else
>      ...
>

That is not an option - that is the code you usually use with  
Suggests: (except for the pkg assignment which is there I presume to  
obscure things).


>
>> But Kurt will we happy to tell you that you can turn off "forcing"
>> suggested packages for checking by setting
>>
>>  _R_CHECK_FORCE_SUGGESTS_=false
>>
>> in your environment.  The idea is that maintainers typically want to
>> fully check their functionality, suggesting to force suggests by
>> default.
>
> Unless the public repositories such as CRAN and Bioconductor decide to
> set this option, it provides no solution for anyone who maintains or
> plans to make available a package through a public R repository such  
> as
> CRAN or Bioconductor.
>
> There is a real need (of some kind) here.  Not all packages work on  
> all
> platforms.  For example, the multicore package provides a mechanism  
> for
> running parallel computations on a multi-cpu box, but it is not
> available on Windows.  A package that _is_ available on all platforms
> should be able to optionally make use of multicore on non-Windows.  I
> don't think there is a way to do that now

... there are 10 packages on CRAN that officially suggest multicore  
and there is no issue with their checks. I suspect you are making up  
an issue here that doesn't really exist ...

  As Kurt pointed out the checking is optional and makes sense to test  
the optional capability. You'd have to ask him but I don't think Kurt  
refuses packages because they suggest something that is not available  
everywhere ...


> and pass check without
> resorting to "tricks" as above.  These tricks are bad as they make it
> harder to programmatically determine the true "suggests".
>

Hence I don't see why your should even pst them ;).

Cheers,
Simon


> And NAMESPACE brings up another issue in that being able to do
> conditional imports would be very useful for these cases, otherwise  
> you
> simply can't make proper use of name spaces for any optional  
> functionality.
>
> I'm willing to help work on and test a solution if we can arrive at  
> some
> consensus as to what the solution looks like.
>
> Best,
>
> + seth
>
> ______________________________________________
> [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: optional package dependency

Uwe Ligges-3
In reply to this post by Seth Falcon-3


On 15.01.2010 16:22, Seth Falcon wrote:

> On 1/15/10 12:19 AM, Kurt Hornik wrote:
>>>>>>> Jeff Ryan writes:
>>
>>> Hi Ross,
>>> The quantmod package makes available routines from a variety of
>>> contributed packages, but gets around your issues with a bit of, um,
>>> trickery.
>>
>>> Take a look here (unless your name is Kurt ;-) ):
>
> I believe another option is:
>
>     pkg<- "somePkg"
>     pkgAvail<- require(pkg, character.only = TRUE)
>     if (pkgAvail)
>        ...
>     else
>        ...
>
>
>> But Kurt will we happy to tell you that you can turn off "forcing"
>> suggested packages for checking by setting
>>
>>    _R_CHECK_FORCE_SUGGESTS_=false


Seth,

the Windows checks for CRAN run with that setting, i.e.

  _R_CHECK_FORCE_SUGGESTS_=false

Hence the multicore issue mentioned below actually does not exist.

Best,
Uwe



>> in your environment.  The idea is that maintainers typically want to
>> fully check their functionality, suggesting to force suggests by
>> default.
>
> Unless the public repositories such as CRAN and Bioconductor decide to
> set this option, it provides no solution for anyone who maintains or
> plans to make available a package through a public R repository such as
> CRAN or Bioconductor.
>
> There is a real need (of some kind) here.  Not all packages work on all
> platforms.  For example, the multicore package provides a mechanism for
> running parallel computations on a multi-cpu box, but it is not
> available on Windows.  A package that _is_ available on all platforms
> should be able to optionally make use of multicore on non-Windows.  I
> don't think there is a way to do that now and pass check without
> resorting to "tricks" as above.  These tricks are bad as they make it
> harder to programmatically determine the true "suggests".
>
> And NAMESPACE brings up another issue in that being able to do
> conditional imports would be very useful for these cases, otherwise you
> simply can't make proper use of name spaces for any optional functionality.
>
> I'm willing to help work on and test a solution if we can arrive at some
> consensus as to what the solution looks like.
>
> Best,
>
> + seth
>
> ______________________________________________
> [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: optional package dependency

Thomas Lumley
In reply to this post by Seth Falcon-3
On Fri, 15 Jan 2010, Seth Falcon wrote:


> There is a real need (of some kind) here.  Not all packages work on all
> platforms.  For example, the multicore package provides a mechanism for
> running parallel computations on a multi-cpu box, but it is not
> available on Windows.  A package that _is_ available on all platforms
> should be able to optionally make use of multicore on non-Windows.  I
> don't think there is a way to do that now and pass check without
> resorting to "tricks" as above.  These tricks are bad as they make it
> harder to programmatically determine the true "suggests".
>
> And NAMESPACE brings up another issue in that being able to do
> conditional imports would be very useful for these cases, otherwise you
> simply can't make proper use of name spaces for any optional functionality.
>
> I'm willing to help work on and test a solution if we can arrive at some
> consensus as to what the solution looks like.
>

Seth,

In the case of multicore it seems to work to put it in 'Suggests' and to use require() to load it. That's what I did with the survey package, and it didn't cause problems on CRAN.  I didn't run CMD check on Windows myself, only on Mac and Linux.

A more difficult issue is providing methods for a generic in another package that might not be available.  I wanted to provide methods on survey objects for generics in odfWeave, and I couldn't find out how to do that without making it required.   I ended up creating a new odfWeave.survey package that depends on odfWeave and survey, but this seems like the sort of thing that should be able to be done with Enhances or Suggests.

     -thomas


Thomas Lumley Assoc. Professor, Biostatistics
[hidden email] University of Washington, Seattle

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

Re: optional package dependency

Ross Boylan
In reply to this post by Kurt Hornik-5
On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote:
> The idea is that maintainers typically want to
> fully check their functionality, suggesting to force suggests by
> default.
This might be the nub of the problem.  There are different audiences,
even for R CMD check.

The maintainer probably wants to check all functionality.  Even then,
there is an issue if functionality differs by platform.

CRAN probably wants to check all functionality.

An individual user just wants to check the functionality they use.

For example, if someone doesn't want to run my package distributed, but
wants to see if it works (R CMD check), they need to be able to avoid
the potentially onerous requirement to install MPI.

Ross

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

Re: optional package dependency

Simon Urbanek

On Jan 15, 2010, at 12:18 , Ross Boylan wrote:

> On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote:
>> The idea is that maintainers typically want to
>> fully check their functionality, suggesting to force suggests by
>> default.
> This might be the nub of the problem.  There are different audiences,
> even for R CMD check.
>
> The maintainer probably wants to check all functionality.  Even then,
> there is an issue if functionality differs by platform.
>
> CRAN probably wants to check all functionality.
>
> An individual user just wants to check the functionality they use.
>
> For example, if someone doesn't want to run my package distributed,  
> but
> wants to see if it works (R CMD check), they need to be able to avoid
> the potentially onerous requirement to install MPI.
>

... that what's why you can decide to run check without forcing  
suggests  - it's entirely up to you / the user as Kurt pointed out ...

Cheers,
Simon

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

Re: optional package dependency (enhances)

Ross Boylan
In reply to this post by Benilton Carvalho-2
On Fri, 2010-01-15 at 10:48 +0000, Benilton Carvalho wrote:
> How about using:
>
> Enhances: Rmpi
>
> ?
>
> b
The main reason is that "enhances" seems a peculiar way to describe the
relation between a package that (optionally) uses a piece of
infrastructure and the infrastructure.  Similarly, I would not say that
a car enhances metal.  The example given in the R extension
documentation ("e.g., by providing methods for classes from these
packages") seems more in line with the usual meaning of enhance.

A secondary reason is that I can not tell from the documentation exactly
what putting a package in enhances does.  The example of adding
functionality to a class suggests that packages that are enhanced are
required.  However, clearly one could surround code that enhanced a
class from another package with a conditional, so that if the code was
skipped if the enhanced package was absent.  Even that logic isn't quite
right if the enhanced package is added later.

My package only loads/verifies the presence of rmpi if one attempts to
use the distributed features, so the relation is at run time, not load
time.

Ross

>
> On Fri, Jan 15, 2010 at 6:00 AM, Ross Boylan <[hidden email]> wrote:
> > I have a package that can use rmpi, but works fine without it.  None of
> > the automatic test code invokes rmpi functionality.  (One test file
> > illustrates how to use it, but has quit() as its first command.)
> >
> > What's the best way to handle this?  In particular, what is the
> > appropriate form for upload to CRAN?
> >
> > When I omitted rmpi from the DESCRITPION file R CMD check gave
> > <quote>
> > * checking R code for possible problems ... NOTE
> > alldone: no visible global function definition for ‘mpi.bcast.Robj’
> > alldone: no visible global function definition for ‘mpi.exit’
> > <quote>
> > followed by many more warnings.
> >
> > When I add
> > Suggests: Rmpi
> > in DESCRIPTION the check stops if the package is not installed:
> > <quote>
> > * checking package dependencies ... ERROR
> > Packages required but not available:
> >  Rmpi
> > </quote>
> > Rmpi is not required, but I gather from previous discussion on this list
> > that suggests basically means required for R CMD check.
> >
> > NAMESPACE seems to raise similar issues; I don't see any mechanism for
> > optional imports.  Also, I have not used namespaces, and am not eager to
> > destabilize things so close to release.  At least, I hope I'm close to
> > release :)
> >
> > Thanks for any advice.
> >
> > Ross Boylan
> >
> > P.S. Thanks, Duncan, for your recent advice on my help format problem
> > with R 2.7.  I removed the nested \description, and now things look OK.
> >
> > ______________________________________________
> > [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: optional package dependency (suggestions/wishes)

Ross Boylan
In reply to this post by Simon Urbanek
On Fri, 2010-01-15 at 12:34 -0500, Simon Urbanek wrote:

>
> On Jan 15, 2010, at 12:18 , Ross Boylan wrote:
>
> > On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote:
> >> The idea is that maintainers typically want to
> >> fully check their functionality, suggesting to force suggests by
> >> default.
> > This might be the nub of the problem.  There are different
> audiences,
> > even for R CMD check.
> >
> > The maintainer probably wants to check all functionality.  Even
> then,
> > there is an issue if functionality differs by platform.
> >
> > CRAN probably wants to check all functionality.
> >
> > An individual user just wants to check the functionality they use.
> >
> > For example, if someone doesn't want to run my package
> distributed,  
> > but
> > wants to see if it works (R CMD check), they need to be able to
> avoid
> > the potentially onerous requirement to install MPI.
> >
>
> ... that what's why you can decide to run check without forcing  
> suggests  - it's entirely up to you / the user as Kurt pointed out ...
>
> Cheers,
> Simon
This prompts a series of increasing ambitious suggestions:

1. DOCUMENTATION CHANGE
I suggest this info about _R_CHECK_FORCE_SUGGESTS_=false be added to R
CMD check --help.

Until Kurt's email I was unaware of the facility, and it seems to me the
average package user will be even less likely to know.  My concern is
that they would run R CMD check; it would fail because a package such as
rmpi is absent; and the user will throw up their hands and give up.

I did find a Perl variable with similar name in section 1.3.3 of
"Writing R Extensions", but that section does not mention environment
variables.  It would also be unnatural for a package user to refer to
it.

Considering there are many variables, maybe the interactive help should
just note that customizing variables (without naming particular ones)
are available, and point to appropriate documentation

2. NEW BEHAVIOR/OPTIONS
On even more exotic wish would be to allow a list of suggested packages
to check.  That way, someone use some, but not all, optional facilities
could check the ones of interest.  Again, even with better documentation
it seems likely most people would be unaware of the feature.

3. SIGNIFICANTLY CHANGED BEHAVIOR
I think the optimal behavior would be for the check environment to
attempt to load all suggested packages, but continue even if some are
missing.  It would then be up to package authors to code appropriate
conditional tests for the presence or absence of suggested packages;
actually, that's probably true even now.

Ross

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

Re: optional package dependency

Seth Falcon-3
In reply to this post by Uwe Ligges-3
On 1/15/10 7:51 AM, Uwe Ligges wrote:
> the Windows checks for CRAN run with that setting, i.e.
>
>  _R_CHECK_FORCE_SUGGESTS_=false
>
> Hence the multicore issue mentioned below actually does not exist.

I did not know that the Windows checks for CRAN used this setting.
My concern was initiated by a Bioconductor package developer wanting to
use multicore and I mistakenly thought the issue would exist for CRAN as
well.  Bioconductor currently uses the default configuration for check
on all platforms.  For the CRAN case, there is no immediate problem.

While there isn't an issue at hand, the approach still seems lacking.
What happens when there is a Windows only package that folks want to
optionally use?  Perhaps public repositories should then not force
suggests for any platforms (do they already?) -- I think that is a
reasonable and simple solution.  But in that case, perhaps the deafult
value should change.

+ seth

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

Re: optional package dependency

Seth Falcon-3
In reply to this post by Simon Urbanek
On 1/15/10 7:47 AM, Simon Urbanek wrote:

>
> On Jan 15, 2010, at 10:22 , Seth Falcon wrote:
>> I believe another option is:
>>
>>   pkg <- "somePkg"
>>   pkgAvail <- require(pkg, character.only = TRUE)
>>   if (pkgAvail)
>>      ...
>>   else
>>      ...
>>
>
> That is not an option - that is the code you usually use with Suggests:
> (except for the pkg assignment which is there I presume to obscure things).

Unfortunately, it _is_ an option, just not a good one :-)

Some packages need to dynamically load other packages (think data
packages) and they will not know ahead of time what packages they will
load.  So there has to be some sort of loop-hole in the check logic.  In
legitimate cases, this is not obscuring anything.  In this case, I think
we agree the use would not be legitimate.

I'm less and less convinced that the force suggests behavior is useful
to anyone.  Package repositories can easily attempt to install all
suggests and so packages will get complete testing.  Package authors
should be responsible enough to test their codes with and without
optional features.  The slight convenience for an author to know that
optional packages are missing is at least equally balanced with the
slight inconvenience of having to change the check configuration in
order to test in the case of missing suggests.

Anyway...

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

Re: optional package dependency

Ross Boylan
On Sat, 2010-01-16 at 07:49 -0800, Seth Falcon wrote:
> Package authors
> should be responsible enough to test their codes with and without
> optional features.
It seems unlikely most package authors will have access to a full range
of platform types.
Ross

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

Re: optional package dependency

Dirk Eddelbuettel

On 16 January 2010 at 10:53, Ross Boylan wrote:
| On Sat, 2010-01-16 at 07:49 -0800, Seth Falcon wrote:
| > Package authors
| > should be responsible enough to test their codes with and without
| > optional features.
| It seems unlikely most package authors will have access to a full range
| of platform types.

For Windows, I use the win-builder.r-project.org more and more. A really
useful tool.  Kudos to Uwe and Olaf for running this.

For OS X, a 'mac-builder.r-project.org' would be very helpful. Just this eve
I discussed OS X build issues ... without having any access to machine with
OS X.

For Linux, the admission to CRAN is a good test. And I dare say the cran2deb
autobuilder Charles and I are running also puts a decent test on things --
even more so that the usual CRAN test as we run builds in so-called pbuilder
chroot so that eg missing dependencies really pop up.

So: 2 up, 1 to go. Any volunteers for scripting OS X towards a builder service?

Dirk

--
Three out of two people have difficulties with fractions.

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

Re: [Rd] optional package dependency (enhances)

Allen S. Rout-2
In reply to this post by Ross Boylan
Ross Boylan <[hidden email]> writes:

> On Fri, 2010-01-15 at 10:48 +0000, Benilton Carvalho wrote:
>> How about using:
>>
>> Enhances: Rmpi


This unique local bestiary of dependencies is quite inconvenient for
anyone trying to connect R with any other system of package
management.  Below, I've included the rather byzantine scheme I've
suggested in another forum for connecting R packages with RPM
packages.  It made my head hurt to write it.


I think that this spectrum of dependencies substantially complicates
the work of anyone who wants to make R easily accessible to
non-systems-administrator users.  I think the R community wants this
accessibility work to be easy, not hard.

IMO, there is a fairly small set of changes in R package ideology
which could make a big improvement:

1) Everything necessary to load a library should be Required. (I
   naively think this means Imports should also be Required, but I may
   be misunderstanding some nuance of Imports)

2) Everything necessary to complete a CHECK should be Required.


That's it.  In this way you now have only two classes of requirements:

- 'Requires', which has essentially the same meaning as it does in
   other dependency graph worlds.

- Other stuff which R authors care about, but the systems
  administrator need not understand.



----

+ The R community is much less sysadmin-y than other
  language communities.  Several positions about correctness which
  lots of admins take as Truth (i.e. dependency cycle == BAD) they
  find to be more of an aesthetic call.  This is reasonable.

+ Different repositories in the R community have independant lives and
  attitudes.  There is modest competition and grumbling between
  maintainers associated with different repos.

+ Package dependencies cross repo boundaries; sticking with the
  'Better' repositories just won't work, and discussion of these
  variations tends to make R folks testy.

 conclusion: The goal of evolving the R packages into a DAG is a
 non-starter.

+ There are four classes of dependency in R-package land: Requires,
  Imports, Suggests, and Enhances.

+ Requires and Imports are required to load the package. [1]

+ Suggests may be required to fully CMD CHECK the package [1]

+ The need for suggests at CMD CHECK can be deactivated by build
  config file. [2]

+ Many of the dependency cycles can be avoided if we ignore Suggests
  as an RPM dependency.

Now, on to opinion:

+ We would like all official packages to have passed a full R CMD CHECK

+ We would like an absolute minimum of manual special case handling.
  It may not be possible to make that amount zero.

So: Here's my suggested procedure for building any single package,
gangked from a message I sent to R-core:

1) Express binary package dependencies according to Depends and Imports.
   I'll call this the 'narrow dependency graph'.

2) As part of the binary package build process, run CHECK
   with R_CHECK_FORCE_SUGGESTS = false.

I'll pull nomenclature out of my ear and call these "built" but not
"checked".

3) Build all binary packages which are downstream according to all of
   Depends, Imports, Suggests, and Extends.  I'll call this the 'broad
   dependency graph'.

4) Install all the packages in the broad dependency graph.

5) for each package in the broad graph, run CHECK with
   R_CHECK_FORCE_SUGGESTS=true.

Then the affected packages are "checked".  Perhaps this can be noted
with a signature.

.... Whew!


----


- Allen S. Rout

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

Re: [Rd] optional package dependency (enhances)

Uwe Ligges-3


On 20.01.2010 20:11, Allen S. Rout wrote:

> Ross Boylan<[hidden email]>  writes:
>
>> On Fri, 2010-01-15 at 10:48 +0000, Benilton Carvalho wrote:
>>> How about using:
>>>
>>> Enhances: Rmpi
>
>
> This unique local bestiary of dependencies is quite inconvenient for
> anyone trying to connect R with any other system of package
> management.  Below, I've included the rather byzantine scheme I've
> suggested in another forum for connecting R packages with RPM
> packages.  It made my head hurt to write it.
>
>
> I think that this spectrum of dependencies substantially complicates
> the work of anyone who wants to make R easily accessible to
> non-systems-administrator users.  I think the R community wants this
> accessibility work to be easy, not hard.
>
> IMO, there is a fairly small set of changes in R package ideology
> which could make a big improvement:
>
> 1) Everything necessary to load a library should be Required. (I
>     naively think this means Imports should also be Required, but I may
>     be misunderstanding some nuance of Imports)
>
> 2) Everything necessary to complete a CHECK should be Required.
>
>
> That's it.  In this way you now have only two classes of requirements:
>
> - 'Requires', which has essentially the same meaning as it does in
>     other dependency graph worlds.
>
> - Other stuff which R authors care about, but the systems
>    administrator need not understand.
>
>
>
> ----
>
> + The R community is much less sysadmin-y than other
>    language communities.  Several positions about correctness which
>    lots of admins take as Truth (i.e. dependency cycle == BAD) they
>    find to be more of an aesthetic call.  This is reasonable.
>
> + Different repositories in the R community have independant lives and
>    attitudes.  There is modest competition and grumbling between
>    maintainers associated with different repos.
>
> + Package dependencies cross repo boundaries; sticking with the
>    'Better' repositories just won't work, and discussion of these
>    variations tends to make R folks testy.
>
>   conclusion: The goal of evolving the R packages into a DAG is a
>   non-starter.
>
> + There are four classes of dependency in R-package land: Requires,
>    Imports, Suggests, and Enhances.


1. You probably mean "Depends" rather than "Requires".
2. You forgot "LinkingTo"



> + Requires and Imports are required to load the package. [1]
>
> + Suggests may be required to fully CMD CHECK the package [1]
>
> + The need for suggests at CMD CHECK can be deactivated by build
>    config file. [2]
>
> + Many of the dependency cycles can be avoided if we ignore Suggests
>    as an RPM dependency.
>
> Now, on to opinion:
>
> + We would like all official packages to have passed a full R CMD CHECK
>
> + We would like an absolute minimum of manual special case handling.
>    It may not be possible to make that amount zero.
>
> So: Here's my suggested procedure for building any single package,
> gangked from a message I sent to R-core:
>
> 1) Express binary package dependencies according to Depends and Imports.
>     I'll call this the 'narrow dependency graph'.
>
> 2) As part of the binary package build process, run CHECK
>     with R_CHECK_FORCE_SUGGESTS = false.
>
> I'll pull nomenclature out of my ear and call these "built" but not
> "checked".
>
> 3) Build all binary packages which are downstream according to all of
>     Depends, Imports, Suggests, and Extends.  I'll call this the 'broad
>     dependency graph'.
>
> 4) Install all the packages in the broad dependency graph.
>
> 5) for each package in the broad graph, run CHECK with
>     R_CHECK_FORCE_SUGGESTS=true.
>
> Then the affected packages are "checked".  Perhaps this can be noted
> with a signature.


All binary packages on CRAN are checked, we do not need a signature.

Recursive reverse dependencies are also checked after updates. Hence you
do not need to worry at all. Be sure we did most of the work already.

Uwe Ligges



> .... Whew!
>
>
> ----
>
>
> - Allen S. Rout
>
> ______________________________________________
> [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: [Rd] optional package dependency (enhances)

Dirk Eddelbuettel
In reply to this post by Allen S. Rout-2

A working system exists at

        http://debian.cran.r-project.org 

with automated builds (ie automated resolutions of both built-time and
run-time dependencies) of over 2000 packages for both 64-bit Linux ("amd64")
and 32-bit Linux ("i386") of the Debian 'testing' distribution.  Charles and
I are not very proficient at publicising this but we fairly decent montly
downloads for something that is still 'beta' (in the Google sense).

The operating system will always have more local knowledge so here we are
trying to fold R's knowledge of its 2000 packages into the larger ecosystem
of the given Linux distributions.  Works for us, but it is a '2.0' approach
as an earlier one failed to scale.  I have made UseR presentations on each
one of these approaches.

Dirk

--
Three out of two people have difficulties with fractions.

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