Using drat repository with source-only packages under Windows/Mac OS

[nbenn]

This is not really an issue (in the sense that it's a drat bug that needs fixing), but more a report on a problem I ran into (as well as others before me #81, #71, #46) and there even exists a (not-accepted) PR for fixing this (among other things): #73.

Following the hurricaneexposuredata idea, I set up a gh-pages based drat repository with the following folder structure:

|- src
   |- contrib
      |- datapackage_1.0.0.tar.gz
      |- PACKAGES
      |- PACKAGES.gz
      |- PACKAGES.rds

and I use this repository in another package by having the following in it's DESCRIPTION

Suggests:
  datapackage
Additional_repositories: https://user.github.io/repo-name

As datapackage does not require compilation (and being a data package, size is not negligible), it does not make sense to add binary sources to the repo.

Unfortunately, under Win/Mac OS such a setup can cause issues, as remotes::install_deps() will fail because utils::install.packages() throws a warning. This can be remedied by doing any of

• set R_REMOTES_NO_ERRORS_FROM_WARNINGS to true (a bit broad, as will apply to all deps)
• you pass type = "source"/specify contriburl which remotes::install_deps() will forward to utils::install.packages() (not ideal in CI environments)
• add some empty PACKAGES files in the appropriate places below bin/ (the solution in added binary repo path in initRepo, also support "account_name/repo_name" format as input… #73)

Personally, I feel that this should either be mentioned in the docs or that parts of #73 should be reconsidered as it did take some time for me to the to the bottom of this. I'm happy to look into salvaging this aspect of #73. What do you think @eddelbuettel?

[eddelbuettel]

Quickly (and happy to chat more)

• if remotes::... has a problem you need to talk to someone else;

• reads from a repository should just work; the use of type="source" is documented and I think we worked out that one has to use this;

• empyt binary packages are a kludge but if you want to use them you can create them;

• we really work in the context of the base R functions install.packages() and update.packages() which, on some platforms, will always go looking for binaries so maybe one just needs to supply such binaries.

Off to a meeting...

All that said, easy things should be easy and "just work". I need to look again at our 'drat-data' paper setup. Maybe we only ever supported source there. Are you mixing source and binary?

[eddelbuettel]

Ok, taking another look. A more narrow PR of just adding placeholder PACKAGES{, .gz, .rds} may make sense. #73 had a number of issues and was a little too hurried and overwhelming at the time.

[nbenn]

While I agree, writing the empty PACKAGES to the repo ist not the most elegant solution on its own, I feel in this case it might be the best we can do. Requiring users to pass non-default type to install.packages() comes with its own problems, one of which (for me at least) is that remotes::install_deps() by default promotes warning to errors and therefore fails. One can override this but all together this leads to things not "just working".

Whether the writing of empty PACKAGES files should be part of drat and whether this should be the default behavior of drat::initRepo() is up to you. We could add a flag like add_bin_paths (other suggestions?) to drat::initRepo() that controls this behavior. Together with a bit of documentation, this should put the issue to rest. But this is just my opinion. As I said in the beginning, this is not strictly a drat bug and therefore does not need fixing.

[kvasilopoulos]

Sorry, I wanted to add it as a reference for my own consumption and I accidentally put it here.

For me adding empty PACKAGES files does the trick. Please let me know if you have a better solution.

[jangorecki]

Maybe users can just set getOption("pkgType"), then they shouldn't need to pass any extra arguments to install.packages or remotes, unless remotes doesn't respect that option.
Note that having PACKAGES.rds file will make R 3.4.4 to fail trying to use your repository. I generally prefer to remove PACKAGES.rds file.

[eddelbuettel]

@FelixErnst Do we have this covered now? Another close candidate?

[FelixErnst]

Depends. The appropriate paths for a package type will only be created, if the first package of this type is added. Without having tested it, this issue probably persist, if only source packages are added.

From my point of view, it is rather a problem of remotes and not problem of drat. I can understand that escalating a warning to an error might makes sense under certain circumstances, but defaulting to the source type on windows or mac is not among them. I would expect the remotes package to investigate the warning message and only trigger an error on other cases.

[eddelbuettel]

Closing this for being out of scope and possibly stale.