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

[Dirk Eddelbuettel]

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.

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. 

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
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org