[R-pkg-devel] Handling Not-Always-Needed Dependencies?
Uwe Ligges
ligges at statistik.tu-dortmund.de
Wed Aug 3 15:52:17 CEST 2016
On 03.08.2016 15:04, Mark van der Loo 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.
I don't see a point for the discussion, because there is even a CRAN
policy that explain the procedure if there is really need (which should
be carefully decided) to break things.
Best,
Uwe Ligges
>>> [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.duncan at 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.duncan at gmail.com <mailto:murdoch.duncan at 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 at r-project.org <mailto:R-package-devel at r-project.org>
>>> mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
More information about the R-package-devel
mailing list