GitHub user parshimers added a comment to the discussion: Managing R support in main and deployments when the R runtime is installed separately
I think this is a very interesting question. I have been thinking about it a bit since this discussion was posted. It is my understanding that today, pretty much everything you would need to run R workflows is possible to do without further editing the source. All that is needed is an R runtime in the CU, and the aforementioned texera-rudf package along with it's dependency rpy2. It might even be the case that having the CU image itself be built on top of another image that contains R could be permissable, but it's not something I am sure about because I don't fully understand how the licensing works out in this manner. It would be hard to find an image with both R and rpy2 as well. It's also not particularly scalable. The more languages and things we want to support, if this trick works, the harder it gets to use other images without altering them. Based on that I think for option 2, having a simple flag that users can turn on if they have enabled the requisite dependencies themselves (understanding the license implications), seems quite doable, as a first step. Autodetection could come later. One could also imagine taking this whole feature (R support) and trying to use it as an example of what parts of the system need to be turned into an interface for extension support. That way users can add their own operators separately in a controlled fashion. GitHub link: https://github.com/apache/texera/discussions/8948#discussioncomment-19050711 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
