Separating R Support into Optional Plugin

[kunwp1]

We're moving R language support to a separate optional plugin due to licensing requirements. We chose a standalone library approach over patch files for better maintainability and user experience.

The Problem

• Texera used rpy2 for R support
• rpy2 is licensed under GPLv2
• Apache projects cannot include GPL dependencies, so we decided to remove the R dependencies from the Texera main repo and manage them separately.
• Solution needed: Separate R support while maintaining functionality

Two Options Evaluated

Option 1: Patch Files ❌

Create a separate repo with patch files that users apply to main Texera.

Why we rejected this:

• High maintenance burden (patches break with every change)
• Not professional (uncommon approach)
• Patch conflicts are inevitable

Option 2: Standalone Plugin ✅ CHOSEN

Create a pip-installable Python package in a separate repository.

# Installation
pip install git+https://github.com/Texera/texera-r-plugin.git

Why we chose this:

• Standard Python packaging
• Easy installation (one command)
• Low maintenance (independent versioning)
• Clean license separation (Apache-2.0 vs GPLv2)

Key Points

Performance

No degradation. The plugin runs in-process, same as before:

Scala → Python Process → rpy2 → R

Backwards Compatibility

Existing R workflows work without modification. Only change: users must install the plugin.

Migration

For R users:

pip install git+https://github.com/Texera/texera-r-plugin.git

For non-R users:
No action needed. Plugin is optional.

[chenlica]

@kunwp1 Thanks. If possible, it will be good to include a diagram visualize these two options.

[kunwp1]

Just added a diagram

[kunwp1]

I created a prototype of the plugin in my personal repository: https://github.com/kunwp1/texera-r-plugin

I suggest the following plan:

1. Open a PR to the Texera main codebase to integrate the plugin and enable R UDF operators when the plugin is installed in the environment.
2. If the PR is approved, I will transfer/copy the repository into the Texera organization (i.e., https://github.com/Texera/texera-r-plugin)
3. Open a follow-up PR to the Texera main codebase to update the Dockerfiles so the plugin is installed when the R plugin option is enabled.

In parallel, we have an ongoing effort to support multiple ports for R UDF operators. Once the repository is in its final location and the integration is in place, we can proceed with that work.

Let me know if you have any comments!

[chenlica]

I agree with this plan. @Yicong-Huang What do you think?

[Yicong-Huang]

I am OK for both methods. The option 1 is kind of short term, easy to implement, but harder to maintain. The option 2 is more standard, in main texera code we could detect if the r-plugin library is installed or not, and only invoke R UDF if it is installed. I am not sure if we want to publish it to pypy though: I'd prefer to publish pytexera first if that's a goal. We could make it installable with setup.py and a readme in the hosted github repo, for now.

[Yicong-Huang]

I would also suggest to name it texera-rudf for short, concise name.

[kunwp1]

I prefer not to publish it to pypi for now.

[kunwp1]

Sounds good. I will rename the repo to texera-rudf and proceed with the plan. For the PRs, I will ask @Ma77Ball to review them.

[kunwp1]

One quick question about the license for the texera-rudf repository: since it depends on rpy2 (GPLv2), my understanding is that texera-rudf may also need to be licensed under GPLv2 (or another GPL-compatible license). Is that correct, and do we need to update/handle the repository’s license accordingly? @Yicong-Huang @chenlica

[Yicong-Huang]

I think it will have to inherit the license of rpy2. Which is fine as this code doesn't belong to Apache

[chenlica]

@kunwp1 Please also confirm with @bobbai00 .

[parshimers]

It doesn't have to inherit the license of rpy2, but it needs to be compatible. For example, MIT or BSD would be fine. ASL2 isn't compatible with GPLv2 to my knowledge because of the patent clauses. The FSF has a list of licenses they consider compatible: https://www.gnu.org/licenses/license-list.en.html .

A lot of the virality issues of GPLv2 here I don't think come in to play, because unless I misunderstand, there is no intention of making a binary distribution of this plugin. Hence, the user will be the one doing the compilation and linking.

[kunwp1]

Thank you for the comment @parshimers. I will use the MIT license.