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

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
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.  
I see.
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. 
Right.
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. 
MinGW doesn't need to be in the package, because you do not want to ship 
the binaries.

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. 
... and perhaps you can even stay with one package rather than two for 
different platforms.

Best wishes,
Uwe
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

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

MinGW doesn't need to be in the package, because you do not
want to ship the binaries.
I meant that I would have to include the source code of MinGW, in order to build the MinGW compiler in some writeable directory of the R-user's computer. This is because without MinGW I wouldn't be able to build PyMinGW. (PyMinGW is a version of Python that - unlike the standard version of Python - does not depend on copy-righted MS dlls.)
... and perhaps you can even stay with one package rather
than two for different platforms.
Very true!

Best wishes,

Guido