[R-pkg-devel] Handling Not-Always-Needed Dependencies?

[Duncan Murdoch]

On 03/08/2016 2:03 PM, Dirk Eddelbuettel wrote:
>
> On 3 August 2016 at 13:44, Duncan Murdoch wrote:
> | On 03/08/2016 11:17 AM, Dirk Eddelbuettel wrote:
> | >
> | > On 3 August 2016 at 16:21, Uwe Ligges wrote:
> | > |
> | > |
> | > | On 03.08.2016 16:14, Dirk Eddelbuettel wrote:
> | > | >
> | > | > On 3 August 2016 at 16:00, Uwe Ligges wrote:
> | > | > | On 03.08.2016 14:24, Dirk Eddelbuettel wrote:
> | > | > | > Then again, users of TravisCI know that just toggling
> | > | > | >
> | > | > | > _R_CHECK_FORCE_SUGGESTS_=FALSE
> | > | > |
> | > | > | I was travelling, hence a delayed response:
> | > | > |
> | > | > | Why users of TravisCI? It is documented in the manual. Setting it to
> | > | >
> | > | > Because Travis breaks your check as it works in a cleanroom with only the
> | > | > specified packages installed. As it (and that is the gist of my argument)
> | > | > should ...
> | > |
> | > | No, because if I suggest a package, I want to check also the code that
> | > | uses a suggested package. So I have to have the package installed.
> | >
> | > But then you are treating Suggests as Depends and installing irregardless.
> |
> | No, it is different from Depends.
> |
> | Depends implies something will be attached to the search list.  Suggests
> | doesn't.  It is more like Imports, but without importing anything.
>
> I am aware of the distinction.  I was talking, or trying to talk, about
> 'conditional' versus 'unconditional' "presence of packages" if you wish.
>
> Depends/Import are the latter, Suggests is the former.
>
> Or it would be if we chose to treat it like that. My gripe is that we don't.
>
> | CRAN chooses to test in an environment where all Suggested packages are
> | available.  They could do more testing (and I am pretty strongly in
> | favour of that), e.g. *also* test in an environment where none of them
> | are available.  But lots of packages will fail those tests, hence my
> | request to you (not a gambit, I'm not playing a game) to estimate how
> | many, and work out how to fix those packages.
>
> I did send a PR to one such package in the past. The package maintainers
> ignored it.  So I stopped.
>
> I think I'll do the same with this thread now.
>
> | Doing more testing will make it harder to get a package accepted on
> | CRAN, but hopefully will mean that if it makes it there, it will be of
> | better quality.
> |
> | The other thing I am trying to do is to work out ways to spread out the
> | work that CRAN does to other people.  I believe the current model will
> | not last another year, and I'd rather that it didn't collapse
> | completely.  This is unlikely to be my only request for help from people
> | on this list.
>
> I actually suggested doing the exact amount of tests, but it differently by
> not forcing Suggests: in.
>
> I have the feeling you seem to think that I want to create more work not
> less. I am not.

No, you are reading something into my messages that isn't there.  I 
think I understand your suggestion now (CRAN should test with no 
Suggested packages present, not with all of them present).  That is less 
work than they currently do.

I disagree with your suggestion for two reasons.

1. I think it would lead to less effective testing.

As Uwe said, tests would skip code that only runs when Suggested 
packages are present.  I think it would almost certainly lead to less 
code coverage in the tests.

2. It would be disruptive during the transition.

We could work around this by putting together a standard way for a 
package to indicate that some functionality is not available, without 
triggering an error, and the check code could ignore those messages when 
testing with missing Suggested packages.

Actually, I think I am the one who is suggesting the creation of more 
work.  In particular, I suggested you should do some work to address 
point 2 above.  I have also suggested that CRAN should test both with 
and without Suggested packages, which is obviously more work for the 
test machines, but also more work for whoever sets up the new testing code.

My hope is to spread the work out to package submitters, or people on 
this list, rather than on two or three people at CRAN.

> I once thought I could influence the 'powers that be' to interpret the policy
> they have written (ie Writing R Extensions) differently.  But I guess I was
> wrong.

There are no powers, there are only overworked volunteers.

Duncan Murdoch


>
> Dirk
>
> | > | > No, CRAN could just flip that toggle and run once.
> | > |
> | > | I do not get it: It won't make much of a difference because I have most
> | > | packages installed. It is only a diffrence for suggested packages that
> | >
> | > Which is a normal shortcut to make your life easier ... but not what other
> | > systems do. Travis CI runs start from scratch with an empty base. So does
> | > Debian for package build (and for subsequent tests such as the
> | > reproducibility tests). In each case only listed packages get installed.
> | >
> | > When we let R do its business Suggests is (currently) interpreted as
> | > Depends. I continue to claim that is not what it is for.
> | >
> | > As Thomas pointed out, Suggests: seems to be overloaded already to two
> | > distinct use cases.
> | >
> | > | are not available for my platform, and toggling it means checks always
> | > | fail then.
> | > |
> | > |
> | > | > What Duncan suggested was (as I understand it an empirically-driven
> | > | > assessment of what it would take to get from here (set to FALSE, tolerate bad
> | > | > Policy) to there (set to TRUE, IMHO better Policy adherence).
> | > |
> | > | You do not understand the environment variable, I believe.
> | >
> | > That is of course entirely possibly but it also seems that some of us in this
> | > discussion are continuously talking past each other. I tried to make my case
> | > but seemingly failed to explain it clearly enough.
> |
> | That's the nature of the medium.  You need to be prepared to say the
> | same thing in different ways so that dense people like me understand them.
> |
> | Duncan Murdoch
> |
>