Skip to content

[R-pkg-devel] Non-mainstream packages in vignette / dependency

6 messages · Peter Meissner, Dirk Eddelbuettel

Original
Peter Meissner
# 
Dear Listeners,

I would like to submit a package to CRAN but I also want to use two  
non-mainstream packages in my vignette. Currently I have them stated in my  
Suggests field but that leads to CRAN/Check complaints -understandably  
since they cannot be obtained by install.packages().

I know, that there is the 'Additional_repositories' field for the  
DESCRIPTION file but as the name (and the CRAN policies) say this is for  
CRAN-like repositories and those two packages (AnomalyDetection,  
BreakoutDetection) are on GitHub (e.g.  
https://github.com/twitter/AnomalyDetection).

Should I simply leave them out of the Suggests - that will lead to  
complaints about non-stated dependencies in vignette.

Should I fake my vignette code so that the troubling part is actually not  
run when building the vignette - that gives me headaches.

Is there some other, clean way ?


Best, Peter



--
Dirk Eddelbuettel
#
On 22 May 2015 at 13:20, Peter Meissner via R-package-devel wrote:
| I would like to submit a package to CRAN but I also want to use two  
| non-mainstream packages in my vignette. Currently I have them stated in my  
| Suggests field but that leads to CRAN/Check complaints -understandably  
| since they cannot be obtained by install.packages().
| 
| I know, that there is the 'Additional_repositories' field for the  
| DESCRIPTION file but as the name (and the CRAN policies) say this is for  
| CRAN-like repositories and those two packages (AnomalyDetection,  
| BreakoutDetection) are on GitHub (e.g.  
| https://github.com/twitter/AnomalyDetection).
| 
| Should I simply leave them out of the Suggests - that will lead to  
| complaints about non-stated dependencies in vignette.
| 
| Should I fake my vignette code so that the troubling part is actually not  
| run when building the vignette - that gives me headaches.
| 
| Is there some other, clean way ?

That is an excellent question that I have no answer to.

It so happens that I did put both of these packages (AnomalyDetection,
BreakoutDetection) into the 'ghrr' repository created by my drat package [1].

So I can install these packages fine as there is now a repo.  What I have not
done is tried to convince CRAN that such a non-CRAN, non-BioC, non-Omegahat
repo passes the implicit test set up by 'Additional_repositories'.

And to the best of my knowledge, nobody else has.  So that is really a CRAN
question.  [2]

Dirk


[1] I have posted / blogged a few times about drat. It basically sits on top
of install.packages() / update.packages() by providing repositories -- which
are super-easy to setup and host at GitHub via their built-in gh-pages
webserver.  See http://dirk.eddelbuettel.com/code/drat.html as well as the
http://ghrr.github.io/drat pages for starting points, or ask me off-list.

[2] So the list is zero days old and already stalled. Wow.  ;-)
Peter Meissner
# 
Am .05.2015, 14:12 Uhr, schrieb Dirk Eddelbuettel <edd at debian.org>:
Hey,

many thanks for the hint to your drat framework. Since it seems, that
adding 'http://ghrr.github.io/drat/' as 'Additional_repositories' in
the package DESCRIPTION file, does fulfill  the !formal! requirements,
I think I will try if I can get through with it and will report the
results to the list.


Installation works out of the box with...

install.packages(
	"AnomalyDetection",
	repos = "http://ghrr.github.io/drat",
	type="source"
)


... and first hurdle Winbuilder (devtools::build_win()) accepts the
DESCRIPTION field ...

Additional_repositories: http://ghrr.github.io/drat


... and notes the following without raising a complaint:

Suggests or Enhances not in mainstream repositories:
   AnomalyDetection, BreakoutDetection

Availability using Additional_repositories specification:
   AnomalyDetection    yes   http://ghrr.github.io/drat
   BreakoutDetection   yes   http://ghrr.github.io/drat


Now my question is what status 'http://ghrr.github.io/drat/' has. Is it a
repo bundling Github published packages open for public and going to stay
there for good? Or is it more a private thing? To put it another way.
Should I use my 'own' fork of your efforts
(http://petermeissner.github.io/drat/) or is it ok that I use ghrr and
I can assume that AnomalyDetection and BreakoutDetection stay there - I
would prefer using ghrr.


Best, Peter
Dirk Eddelbuettel
#
On 22 May 2015 at 17:31, Peter Meissner wrote:
| many thanks for the hint to your drat framework. Since it seems, that
| adding 'http://ghrr.github.io/drat/' as 'Additional_repositories' in
| the package DESCRIPTION file, does fulfill  the !formal! requirements,
| I think I will try if I can get through with it and will report the
| results to the list.

Awesome!
 
| Installation works out of the box with...
| 
| install.packages(
| 	"AnomalyDetection",
| 	repos = "http://ghrr.github.io/drat",
| 	type="source"
| )
| 
| 
| ... and first hurdle Winbuilder (devtools::build_win()) accepts the
| DESCRIPTION field ...
| 
| Additional_repositories: http://ghrr.github.io/drat
| 
| 
| ... and notes the following without raising a complaint:
| 
| Suggests or Enhances not in mainstream repositories:
|    AnomalyDetection, BreakoutDetection
| 
| Availability using Additional_repositories specification:
|    AnomalyDetection    yes   http://ghrr.github.io/drat
|    BreakoutDetection   yes   http://ghrr.github.io/drat

Wickedly cool. I didn't even think about trying that yet!
 
| Now my question is what status 'http://ghrr.github.io/drat/' has. Is it a
| repo bundling Github published packages open for public and going to stay
| there for good?

That is the idea! You will note that I didn't put my name anywhere to keep it
neutral.  On the other hand I didn't want to be 'too annoying' about it and
have not pushed it too hard yet.  I gave commit rights to a collaborator who
expressed interest in using it, but he is still at 'trying first with a local
repo' stage and has not pushed anything ... 

| Or is it more a private thing? To put it another way.
| Should I use my 'own' fork of your efforts
| (http://petermeissner.github.io/drat/) or is it ok that I use ghrr and
| I can assume that AnomalyDetection and BreakoutDetection stay there - I
| would prefer using ghrr.

It is up to you. You have choices.

You could pat and hope that the repo will be there.  I have tried all these
years to build up some karma and trust that things I maintain won't disappear
over night -- but one can never know, can one? ;-) If you'd rather use your
own drat repo, that is entirely within the spec.  Nobody can stop you.

"We" as a community have barely started to figure if additional repos can and
will work.  But what you did here is very exciting and encouraging for drat,
so thumbs up from me!

Cheers, Dirk

PS I already have three drat repos because one is for the drat code proper, I
opened one just for Rcpp and related, and this third 'general' one under the
'ghrr' handle. It has already proven to very useful for myself and colleagues
as I use to feed a bunch of servers at work with packages not otherwise on a
repo.  Such as RcppR6 by Rich, Rblpapi by Whit/myself/John, the breakout and
anomaly packages you use, and some more.
Peter Meissner
# 
So I pat and hope for the best ...

and am happy to have used ghrr as additional repo for my CRAN submission.  
CRAN agrees and has accepted wikipediatrend with ghrr as an additional  
non-mainstream package-repo. Thanks again.

I think having one additional repo for packages that are on GitHub but not  
on CRAN is a splendid idea and the word about ghrr shall be spread loud  
and wide. Great work.

My personal drat repo then will remain for personal toolkit delivery.


Best, Peter




Am .05.2015, 17:58 Uhr, schrieb Dirk Eddelbuettel <edd at debian.org>:
--
Dirk Eddelbuettel
#
On 23 May 2015 at 10:57, Peter Meissner wrote:
| So I pat and hope for the best ...
| 
| and am happy to have used ghrr as additional repo for my CRAN submission.  
| CRAN agrees and has accepted wikipediatrend with ghrr as an additional  
| non-mainstream package-repo. Thanks again.

Very nice existence proof -- congrats.

I'll reference that in the drat FAQ. I am due a package update anyway.
 
| I think having one additional repo for packages that are on GitHub but not  
| on CRAN is a splendid idea and the word about ghrr shall be spread loud  
| and wide. Great work.

And GitHub style pull requests (or issue tickets) may be the best way to add
more package.  Not sure I documented that somewhere but I tend to use

   "name of package"   "version"   "git sha1"   "repo url"

as a commit format so that it is always clear where a package came from.
* 6dcf413 - Rblpapi 0.2.2.5 f7ff208 git at github.com:eddelbuettel/Rblpapi.git (22 hours ago) <Dirk Eddelbuettel>
* 955771d - BH 1.58.0-0 2b6afe8 git at github.com:eddelbuettel/bh.git (9 days ago) <Dirk Eddelbuettel>
* 24be658 - AnomalyDetection 1.0.1 845527d git at github.com:eddelbuettel/AnomalyDetection.git (12 days ago) <Dirk Eddelbuettel>
* ed7f30d - Rblpapi 0.2.2.4 7e332bc git at github.com:eddelbuettel/Rblpapi.git (12 days ago) <Dirk Eddelbuettel>
* a1c49c8 - BreakoutDetection 1.0.1.1 2121f8c git at github.com:eddelbuettel/BreakoutDetection.git (12 days ago) <Dirk Eddelbuettel>

For BreakoutDetection and AnomalyDetection, I used local forks so that I
could increment the minor version to make the (then-current) git snapshot I
took distinct. Both had (minor) recent changes in there that made it a little
distinct from the earlier, announced versions -- and in cases like that I
think the version number really ought to be distinct as the code.

"That's what forks are for." :)

Similarly, the BH above was a pre-release I announced to rcpp-devel; it has
since been superseeded by the BH 1.58.0-1 release now on CRAN.

| My personal drat repo then will remain for personal toolkit delivery.

Sounds like a plan.

Dirk