Including external executables in R package

Tags: #<Tag:0x00007f0ea23d0790>

I’d like to include small executables of standalone libraries into an R package that should go to CRAN.

However, CRAN seems to reject packages that include such executables by default according to Writing R Extensions: 1.1 Package structure

Note that CRAN will no longer accept submissions containing binary files even if they are listed.

I’d like to include the executable because the application in question is only downloadable from a website (binaries for different OS) and not installable via a package manager.
To use it, users would need to download it, put it into their $PATH or provide a path to the executable.
This usually is a blocker for some non-experienced people which I’d like to avoid.

Does anyone have experience with this topic?

I was also thinking about separate CRAN/GitHub versions of the package where only the GitHub package would come bundled with the executables. But this also increases maintenance effort and makes things confusing.

1 Like

I cannot help much, but just to clarify, you don’t have access to source files, right?

I was also thinking about separate CRAN/GitHub versions of the package where only the GitHub package would come bundled with the executables. But this also increases maintenance effort and makes things confusing.

Maybe your package could include a function install_exec() that would help the user install the executable, i.e. it would download it and provides guidelines about the installations steps that would vary according to user’s OS. This function could be triggered by any function that requires the executable (and so you’d need to test whether the executable is already installed, etc.).

As for the maintenance, it may be worth proceeding this way for both the GitHub and CRAN package.

Hope this could be useful.

Thanks Kev.

Yes, the source is not available. I already contacted the author but the app was last updated in 2006 so I do realistically not expect a positive turnout.

install_exec() could be a solution, yes. Some verbose instructions what is going to happen and then do all the work. Seems legit.

1 Like

the phylocomr pkg has executables in the installed package GitHub - ropensci/phylocomr: Phylocom R interface They aren’t in the source though, so maybe it’s a different situation.

any ideas @jeroenooms ?

If the source code is available, did you try building the executables from source? See the antiword or unrtf package for more examples.

The source code is not available, only the binaries. I’d like to compile the source myself, creating valid macOS executables also.

Here’s the app’s site: CLUTO download | Karypis Lab.

It is close source, so unless the original author do a new release under a different licence, I don’t think you could get access to the source. There are some more details in Kurt Hornik et al. 2012 that make me feel that including this in a package is kind of conflicting with CRAN’s policy. I might be wrong about that.

Yeah I guess you are right. I also interface it via {skmeans} for a particular use case in my package.
It is just one of many options my package will offer and it is not that much of a deal breaker.

I’ll just write a wrapper function for installing the binary. Given that the site seems static since 2006, I hope this effort lasts quite some time.

I think that even a wrapper installing that binary would be problematic given the “licence” that governs its use:

The software may not be sold or redistributed without prior approval

At this point the best you could probably do is ask the users to install it themselves somewhere and tell you where it is (e.g., via a PATH_CLUTO environment variable)

Thanks Rich.

I wonder if a wrapper function is already in the scope of “redistribution” here.
Calling the function would require action by a user and before calling it, one should/could read the help page of the function (in theory).

Maybe a confirmation dialog within the download function could make the action “more safe/legal”?

You would at the least need to check that the user understands what the licence says they can and cannot do with the program (e.g., “commercial” use, which does include grant funded research in many countries, is not permitted). In your position, I would not want to be held responsible for helping people circumvent a licence like that. Realistically, I doubt the authors care that much, but I would probably not expose myself by wrapping downloading it, especially if you’ve not heard anything back from the authors.

ETA: if you find yourself wondering what would be legal or not in a situation - please talk to a lawyer!