Re: [Rd] optional package dependency (enhances)
tl;dr: Repackaging in native formats dramatically improves user access to packages. >> On Wed, 20 Jan 2010 20:23:51 +0100, Uwe Ligges >> said: > 1. You probably mean "Depends" rather than "Requires". > 2. You forgot "LinkingTo" Heh, thanks! I'll add them. > All binary packages on CRAN are checked, we do not need a signature. Since you don't generate e.g. RPMs, every packaging system is forced to re-do this work. I was talking about that signature, the one on the RPM. > 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. Some of us care a lot about automatically understanding the installed packages on a system. This lets us do things like cleanly and consistently produce a new one "like that". This goal is very important to many sysadmin types. It is intractible to ask, e.g. R, Perl, Python, Ruby, Mozilla, etc... essentially every application that came up with a plugin or module system, "Hey, what do -you- think is installed". It is also extra overhead to expect each system administrator to go learn CPAN, jpp, ppi, gems, CRAN, etc... it adds myriad extra steps to the analysis and configuration of machines. On the other hand, many R developers appear to live in a world of machines which are unique flowers, and they expect that other machines with which they interact will be nurtured in the same individual way. This is not "bad", it is just "different"; but the architectural decisions which are completely reasonable in a world of individual gardens place restrictions on those who would like to plant 100 or 1000 machines, all identical. If we on the borders connecting R to [distribution in question] can easily repackage R software, then the utility of R to the world will increase. I think this would be a good thing. I understand that it's not a big priority for that fraction of R-devel who lives amongst their gardens, and I'm not offhand expecting some mass conversion here. :) But I wanted to make the case. - Allen S. Rout __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency (enhances)
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.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency (enhances)
On 20.01.2010 20:11, Allen S. Rout wrote: Ross Boylan writes: On Fri, 2010-01-15 at 10:48 +, 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency (enhances)
Ross Boylan writes: > On Fri, 2010-01-15 at 10:48 +, 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency (suggestions/wishes)
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency (enhances)
On Fri, 2010-01-15 at 10:48 +, 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 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
> >
> > * 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’
> >
> > followed by many more warnings.
> >
> > When I add
> > Suggests: Rmpi
> > in DESCRIPTION the check stops if the package is not installed:
> >
> > * checking package dependencies ... ERROR
> > Packages required but not available:
> > Rmpi
> >
> > 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.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
How about using: Enhances: Rmpi ? b On Fri, Jan 15, 2010 at 6:00 AM, Ross Boylan 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 > > * 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’ > > followed by many more warnings. > > When I add > Suggests: Rmpi > in DESCRIPTION the check stops if the package is not installed: > > * checking package dependencies ... ERROR > Packages required but not available: > Rmpi > > 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. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
> 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 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 >> >> * 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’ >> >> followed by many more warnings. >> >> When I add >> Suggests: Rmpi >> in DESCRIPTION the check stops if the package is not installed: >> >> * checking package dependencies ... ERROR >> Packages required but not available: >> Rmpi >> >> 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. >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- > Jeffrey Ryan > jeffrey.r...@insightalgo.com > ia: insight algorithmics > www.insightalgo.com > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
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 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 > > * 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’ > > followed by many more warnings. > > When I add > Suggests: Rmpi > in DESCRIPTION the check stops if the package is not installed: > > * checking package dependencies ... ERROR > Packages required but not available: > Rmpi > > 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. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
