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
