The issue seems to boil down to the fact that Suggests is covering two very different use cases: (a) conditional package code and (b) example/test/vignette code.
Consider a package (say "foo") that is only used in tests. Users do not need "foo" since package code never calls it. If our package instead calls "foo" conditionally (requireNamespace(); foo::bar(), etc.), then users may very well want "foo" and need it much more than they would if "foo" were only used in tests. Yet DESCRIPTION does not allow a distinction two be made between these two scenarios. I think the length and complexity of the discussion in WRE[1] makes clear that Suggests is being used two cover these two very different use cases. -Thomas [1] https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Package-Dependencies Thomas J. Leeper http://www.thomasleeper.com On Wed, Aug 3, 2016 at 2:04 PM, Mark van der Loo <mark.vander...@gmail.com> wrote: >>> Recommends: only gets installed, can be used via if(requireNamespace()) >>> from the package and in pkg tests[1] [snip] >>> Build-Depends: gets installed before build, removed after. >>> Suggests: only installed when requested at install.packages() and only >>> used in examples/vignettes. > > [snip] >> I'd much rather >> have a way of declaring explicitly the different aspects of dependence >> on a package rather than bundling them up into cute labels, > > Agreed > >> but it's too late for that now. However, we don't need to make things >> worse. > > Disagreed. We could follow the well-established practices of Debian (and > CRAN already does that, partially). > > >>> If 'tons of packages' are using if(requireNamespace) in their package >>> code there seems to be a need for something like this. [snip] > >> I don't follow the argument here. What problem are you solving? > > Basically I'm trying to address the idea suggested by Thomas, who started > this conversation, and make it a bit more explicit. I felt that the > discussion went a little off-track there. > > Right now, when package code (not examples) uses a suggested package, part > of that package will by default not work - at least that's how people use it > now. I would like it to work by default. For examples/vignettes you could be > more forgiving since running an example is not core functionality of a > package. > >>> Perhaps more controversially a 'Breaks' field could be considered. [snip] > >> This isn't controversial, it's just a bad idea. Don't encourage people >> to break things. > > Your reaction just proved my point about it being controversial. More > seriously, real progress is hardly ever possible without breaking things, so > I think at least people could have a serious discussion about it before > dismissing it simply as a bad idea. The Debian community obviously once > thought it was a good idea, so why not discuss it for R/CRAN? (discussions > are also an important way to progress even if no line of code is changed). > At the moment, I'm inclined against the idea, but I for one like to see me > proven wrong. > > >>> [1] actually, once we know a pkg is Recommended, the >>> 'if(requireNamespace)' could even be absorbed in the :: operator. > >>I don't see how :: would be any different than it is now. If you don't >>have foo available, and you try to use foo::bar(), what would happen >>other than an error? > > I think you're right there. <resets brain>. > > Best, > Mark > > > Op wo 3 aug. 2016 om 13:41 schreef Duncan Murdoch > <murdoch.dun...@gmail.com>: >> >> On 03/08/2016 5:32 AM, Mark van der Loo wrote: >> > >> > After reading the link in Dirk's initial reply, how about adding fields >> > 'Recommends' and 'Build-Depends' to DESCRIPTION as in Debian? >> > >> > Recommends: only gets installed, can be used via if(requireNamespace()) >> > from the package and in pkg tests[1]. [Debian: The Recommends field >> > should list packages that would be found together with this one in all >> > but unusual installations.] >> > Build-Depends: gets installed before build, removed after. >> > Suggests: only installed when requested at install.packages() and only >> > used in examples/vignettes. >> >> I think the distinction between Recommends and Suggests is too subtle >> here. I already think it's a bad thing that we are using these words in >> ways that don't really correspond to English usage. I'd much rather >> have a way of declaring explicitly the different aspects of dependence >> on a package rather than bundling them up into cute labels, but it's too >> late for that now. However, we don't need to make things worse. >> >> > >> > If 'tons of packages' are using if(requireNamespace) in their package >> > code there seems to be a need for something like this. Compliance to the >> > above can be checked automatically and a gradual implementation via >> > NOTE->WARNING->ERROR in R CMD check seems possible. >> >> I don't follow the argument here. What problem are you solving? >> >> > Perhaps more controversially a 'Breaks' field could be considered. There >> > are a few packages out there that have many, many, dependencies. >> > Implementing breaking updates currently depends on the willingness of >> > many authors to update their package or convincing the CRAN maintainers >> > to allow for (temporary) breakage. >> >> This isn't controversial, it's just a bad idea. Don't encourage people >> to break things. >> >> > The suggestion to have functions auto-install things is very >> > inconvenient for the good reasons pointed out by Thomas. Additionally, >> > it is often based on the wrong assumptions. Example: the RGtk2 package >> > has this habit of trying to install when libgtk2 is not on the path. But >> > in my case that is often exactly the case: it is just not on the path >> > (libgtk2 is on the network, the VM just doesn't know yet). So I'd rather >> > have a proper and accurate error message (which is good practice >> > anyway). >> > >> > >> > Best, >> > Mark >> > >> > [1] actually, once we know a pkg is Recommended, the >> > 'if(requireNamespace)' could even be absorbed in the :: operator. >> >> I don't see how :: would be any different than it is now. If you don't >> have foo available, and you try to use foo::bar(), what would happen >> other than an error? >> >> Duncan Murdoch >> >> > >> > >> > >> > >> > Op wo 3 aug. 2016 om 01:46 schreef Duncan Murdoch >> > <murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>>: >> > >> > On 02/08/2016 6:34 PM, Dirk Eddelbuettel wrote: >> > > >> > > On 2 August 2016 at 18:13, Duncan Murdoch wrote: >> > > | Okay, now I think I understand, but I agree with CRAN. It is >> > not >> > > | feasible to tell if the test happened somewhere in the code >> > unless we >> > > | enforce a particular way of writing the test. >> > > >> > > Debian has well over 20k packages, and they are tested this way. >> > You just >> > > need to show the will of testing in an _empty_ environment to >> > ensure >> > > _everything_ that is needed is loaded. >> > > >> > > | I would object if I had to write if (requireNamespace("foo")) >> > multiple >> > > | times just to satisfy CRAN's test, when any sane human could >> > tell that >> > > | the first test was sufficient. >> > > | >> > > | For example, if my package Suggests: foo, I should be able to >> > write >> > > | >> > > | if (!requireNamespace("foo")) >> > > | stop("Package foo is needed for this example") >> > > | >> > > | and then merrily call foo::bar() as many times as I like. >> > > | >> > > | Or am I still misunderstanding you? What particular thing >> > should CRAN >> > > | change? >> > > >> > > You seem to misunderstand that both you and I want >> > > >> > > if (!requireNamespace("foo")) >> > > stop("Package foo is needed for this example") >> > > >> > > (or alternative per-call tests) and that CRAN does not enforce >> > either. >> > > >> > > CRAN, like Hadley, just closes its eyes, swallows hard, and then >> > simply loads >> > > everything treating Suggests as if it were Depends. >> > > >> > > But it ain't. Suggests != Depends. >> > > >> > > Now clearer? >> > >> > >> > So really what you're suggesting is that CRAN should run tests with >> > the >> > suggested packages absent. Presumably tests should also be run with >> > them present. >> > >> > But if they did that, the code that I want to write would call >> > stop() >> > and fail. So we'd need some way to say "Let the user know they need >> > 'foo' to run this, but don't fail." And we'd need to phase this in >> > really gradually, because tons of packages are using code like my >> > example. >> > >> > You volunteered to help CRAN package checking. Why not put together >> > code to implement your idea, and see how big the problem would be to >> > phase it in, by seeing how many packages fail under it? >> > >> > Duncan Murdoch >> > >> > ______________________________________________ >> > R-package-devel@r-project.org <mailto:R-package-devel@r-project.org> >> > mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > >> > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel