dt revdep needs to accept permanent lib dir

[berndbischl]

the docs of check_cran say:

libpath: Path to library to store dependencies packages - if you you're doing this a lot it's a good idea to pick a directory and stick with it so you don't have to download all the packages every time

We currently set to temfile("Rlib"). This ensures that always all deps are downloaded again. For BBmisc this is 130 pkgs, even for BE this is extremely slow.

[berndbischl]

I have set the path to USERHOME/.dt/rlib now.
This makes repeated calls at least cheaper.

I also had to touch the handling of the return value of check_cran again. IIRC I had to do this before. The R docs of this function also seem wrong.

[berndbischl]

More importantly: Why dont we call revdep_check?

It is a bit annoying that apparently nobody besides me seems to call this function?
I have wasted now too much time on this. I pushed a maybe not perfect version.

It does not set an exit code, but at least it runs.
It should be reviewed.

[mllg]

he docs of check_cran say:

libpath: Path to library to store dependencies packages - if you you're doing this a lot it's a good idea to pick a directory and stick with it so you don't have to download all the packages every time

We currently set to temfile("Rlib"). This ensures that always all deps are downloaded again. For BBmisc this is 130 pkgs, even for BE this is extremely slow.

This function is marked as internal. revdep_check uses the option devtools.revdep.libpath, and so should we.

I also had to touch the handling of the return value of check_cran again. IIRC I had to do this before.

Nope, you did not.

More importantly: Why dont we call revdep_check?

Because I wanted to have an exit code and more control over the output. Especially the last lines printing the failed packages was extremely helpful.

It is a bit annoying that apparently nobody besides me seems to call this function?
I have wasted now too much time on this. I pushed a maybe not perfect version.
It does not set an exit code, but at least it runs.
It should be reviewed.

I don't see your point. The previous version was working for me (and returning a meaningful exit code was replacing a cat with an exit). I would rather revert then "review" the unfinished code.

[berndbischl]

Nope, you did not.

I dont get what is happening here.

1. Check the logs. From December.

2. Then revert the change. Then you a reverse check of BBmisc, with current packages from CRAN.
   (Which you should have done anyway)
   Then we can continue.

[berndbischl]

And also:

This function is marked as internal.

Yes exactly. Which is the the only thing that makes sense in your post. And that implies we should not use it.
I wasted a lot of time yesterday, because the function was not working. Then I tried to repair this, figured out it is documented incorrectly and reported that (at devtools), more time wasted.

The conclusion is: Don't rely on stuff other people mark as internal. Otherwise this happens.

It is also possible to use the output of the public function to generate an exit code, just like before.
I just have other things todo now, and could not do this during a long night yesterday.

[mllg]

I dont get what is happening here.

1. Check the logs. From December.

This was not reverted. The exit code stuff has been there since December.

2. Then revert the change. Then you a reverse check of BBmisc, with current packages from CRAN.
   (Which you should have done anyway)
   Then we can continue.

Worked perfectly with devtools 1.6.1.

It is also possible to use the output of the public function to generate an exit code, just like before.
I just have other things todo now, and could not do this during a long night yesterday.

Then create a new branch for unfinished work instead of pushing it to the master.