Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does using extendr affect the minimal supported R version? #375

Open
etiennebacher opened this issue Aug 6, 2024 · 5 comments
Open

Does using extendr affect the minimal supported R version? #375

etiennebacher opened this issue Aug 6, 2024 · 5 comments

Comments

@etiennebacher
Copy link
Contributor

Related to etiennebacher/astgrepr#28

Compiling astgrepr from source fails on R 4.0.3 with this error:

error[E0425]: cannot find value `S4SXP` in this scope
   --> /tmp/RtmpRgdx7u/R.INSTALL1ae525e0ee11/astgrepr/src/vendor/extendr-api/src/lib.rs:574:15
    |
574 |         S4 => S4SXP,
    |               ^^^^^ not found in this scope

For more information about this error, try `rustc --explain E0425`.
error: could not compile `extendr-api` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
make: *** [Makevars:19: rust/target/release/libastgrepr.a] Error 101

I suppose this is because extendr takes advantage of new features in R, so compiling from source won't work for older versions of R. But does this mean users on R 4.0 won't be able to install the binary as well?

More generally, does using extendr affect the minimal R version supported? If so, this should be documented somewhere but I didn't find anything on this.

@etiennebacher etiennebacher changed the title Does using extendr affect the minimal R version supported? Does using extendr affect the minimal supported R version? Aug 6, 2024
@CGMossa
Copy link
Member

CGMossa commented Aug 6, 2024

So I think we have a feature gate for this, so it should work for older versions of R. In theory. Something could have slipped up.

I believe we only don't support the R version that still had 32-bit support, because that's too much for us to handle. But that's an unofficial policy that I'm just speaking of here.

There could be a bug, I'm unsure :( I don't have time to investigate unfortunately. But if you do try to investigate it, I'm sure you'd find a bug somewhere.. I have feature flags in extendr for this.

@etiennebacher
Copy link
Contributor Author

etiennebacher commented Aug 6, 2024

I also don't have time to search for this, especially since I'm not familiar at all with the codebase, but I think a message when initializing rextendr (or even automatically update the DESCRIPTION with Depends: R (>= x.y.z)) would be welcome.

@etiennebacher
Copy link
Contributor Author

Related: extendr/extendr#664

@Ilia-Kosenkov
Copy link
Member

You might be able to get away by referencing older versions of extendr. {rextendr} itself depends on R >= 4.0, and should not use features from later versions.

R (>= 4.0)

We provide support for current, oldrel and devel versions of R (current, previous and future minor versions).

You might also be able to use latest extendr with bindgen, but then it will require having heavy clang integration in order to generate bindings for the version of language that you use.

@etiennebacher
Copy link
Contributor Author

You might be able to get away by referencing older versions of extendr.

I think having a document referencing the versions of R that are supported in each version of extendr would be very useful. For example a table like:

extendr version Oldest supported R version
0.6.0 4.0
0.7.0 4.2

I just put some random R versions here.

We provide support for current, oldrel and devel versions of R (current, previous and future minor versions).

If you don't want to have this kind of table and only provide support for current, oldrel-1, and devel, then I think this should be reflected in the DESCRIPTION when running rextendr::use_extendr().

Another alternative would be to have features for each R version, so that one can have:

extendr-api = { version = "0.7.0", features = ["R-4.1"], optional = true }

(but I don't know if this is hard to implement). Currently, it's impossible to know which of the features blocks some versions of R. I have no idea which approach is the best in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants