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

[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]

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?

[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]

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.

[eddelbuettel]

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

[eddelbuettel]

Closing this for being out of scope and possibly stale.