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
Feature Request: Make RCall depend dynamically on R_HOME
#513
Comments
R_HOME
. Make RCall depend dynamically on R_HOME
R_HOME
Probably you will need to make the changes for this yourself. It will require some restructuring of the package to not use stuff from libR during the precompile stage, so I think it might require figuring out some package internals which may take some time. You may have better luck getting a PR merged. That said, I didn't really understand under what circumstances the preferences approach does not work. Did you try installing my PR? I have been using it together with CondaPkg just fine in my own projects. What steps did you attempt?
My PR solves this problem by aborting precompilation if there is no valid R_HOME. This will not cause a failure, merely a warning. Once you set things up with preferences, the preferences system will automatically trigger a recompilation of RCall.jl. Currently, you have to set the preferences up manually or using a helper script (I have posted the latter in the PR), but once the PR is merged we can either a package extension or create a mini-helper package which will set up the preferences automatically giving a higher level of convenience. |
You might find it informative to read through my PR and my comments since it contains a lot of relevant information to what you are writing. With regards to
Please see:
|
Instructions on how to test my branch together with ConadPkg are here: JuliaPy/CondaPkg.jl#100 (comment) Please let me know if you have any problems or have identified any issues, and I will be happy to discuss and attempt to address. In case you have looked more closely at the different approaches and happen to decide my PR is a reasonable approach, getting behind it could help it get merged. |
Thank you frankier for all your comments and help. What you write sounds pretty good. (Only that other packages call RCall's My biggest wish is that
It seems to me that the preferences approach has the difficulty of managing the interaction between step 1. and step 2. |
I guess you could solve this by having a dummy variable in LocalPreferences.toml which indicates whether this is the first instantiation or a subsequent normal build... Not sure whether this would work. |
This surprised me at first, but this is in fact always the case. It's not spelled out in https://docs.julialang.org/en/v1/manual/modules/#Module-initialization-and-precompilation - which only mentions that
I definitely see what you're getting at -- that it would be convenient to set-up In the future, it should be possible to create some kind of post-install CondaPkg hook to automate this, so that the preference is only set up when R actually becomes available. However, using the preference system to configure |
I agree that Preferences improve the situation. It is just that dynamic resolution is still more handy than Preferences. |
Sure. One concrete advantage I can see is that we wouldn't end up with one copies of RCall.jl bytecode for each R installation. |
I am using RCall with CondaPkg. I know there is currently a pullrequest which uses preferences to set R_HOME. I realized that this would still not be enough for certain setups. I want to sketch why it would be good if RCall's build does not depend on R_HOME.
Ideal World
When installing something which depends on RCall with R provided by CondaPkg, then what you would like to do is
CondaPkg.resolve()
)ENV["R_HOME"] = joinpath(CondaPkg.envdir(), "lib", "R")
)Current World
The above unfortunately does not work but is immensely more complicated. The reason is that building RCall depends on R_HOME and a valid R_HOME. Hence step 1. the instantiation will fail, as R cannot find a valid R_HOME.
So instead currently you need to do
CondaPkg.resolve()
)joinpath(CondaPkg.envdir(), "lib", "R")
and finish julia[EDIT added]
Probably, this approach has still difficulties instantiating CondaPkg conda packages correctly, because it should also grab CondaPkg.tomls from depend projects in the julia load path. But as they are not yet instantiated, it probably does not pick them up. So I guess instead of this step 2, what you actually would need to do is to write your own instantiate method which instantiates everything but RCall and those depending on RCall. And then still CondaPkg would probably miss the conda dependencies of those who depend on RCall - they would need to be manually integrated without triggering a build of RCall.
Conclusion
It would be so much cleaner and simpler if RCall's build would not depend on R_HOME.
RCall's
__init__
method can of course still happily depend on R_HOME.The text was updated successfully, but these errors were encountered: