[Rd] Including a binary Python Interpreter into a binary R-package for MS Windows

[Guido van Steen]

Sorry: I sent this email to R-devel at R-project.COM. So that it got bounced.

Hi Uwe, 

Thanks a lot for this answer. 

> Don't know Python on Windows so well, but why can't they
> install it? You can also install R with limited user
> privileges.

The last time I worked with Python on MS Windows was about 10 years ago. From that time I remember that you needed administrative privileges to install Python (1.5). For some reason this idea got stuck in my mind. I have just tried an ordinary user-install of Python 2.6.2 within a Virtual Machine (XP). I experienced no problems at all. So, you are right: this user-rights argument is invalid. 

> Well, but much of that space is useless/wasted for
> non-Windows users then.

This gave me to the idea to create a package with a slightly different name. It would be an MS Windows only package.  

> Most R users under Windows won't have Rtools installed,
> just the developers will have.

I did not know that. So I guess many R users also miss the Perl dependent scripts. 

> Can't you add some configure script / Makefile that allows
> to build the binary from sources that you provide in your
> package?

Well, that would make the package really bloated. I would first have to build the MinGW compiler, and then I would have to use MinGW to build Python. 

> Otherwise, what you could do is to install the binary on 
> demand from another side you are hosting. E.g. 
> library("write2xls") could check if the required binary is 
> available and install on demand if it is not available. 

This is the kind of idea I am looking for! Thanks very much! Indeed, this would circumvent the whole need of including the Python binaries in an R-package. 

I also like Gabor's idea to run Python scripts from Jython. As he explained, this makes Python available to anyone with access to Java. This might also be acceptable for those users who abhor binary downloads in general. On the other hand it might make the package slow because of longer loading times. 

> If MIT allows to ship things the way you plan to, then it's
> fine, but no binaries in sources packages on CRAN. We did
> quite some work to get rid of the packages that did (even my
> own package!) and won't make exceptions. We won't revert our
> decision.

Very good! I fully support the decision! 

Best wishes, 

Guido