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

Post install/update hook #121

Closed
frankier opened this issue Nov 24, 2023 · 3 comments
Closed

Post install/update hook #121

frankier opened this issue Nov 24, 2023 · 3 comments

Comments

@frankier
Copy link
Contributor

It would be useful if there were a way to have post-install/update hooks. Then projects which wanted to integrate CondaPkg and RCal.jll could simply install a glue package e.g. CondaPkgRCall.jl, which would install a hook which would listen for R to be installed, and when it was would set up a libR preference for RCall.jl to be able to find it.

I'm also interested if there are alternatives to a simple hook, so that things would work nicely with different backends e.g. Null where we would ideally want an event when were were in an environment with R in (but we could also just check for this backend in __init__)

Related discussion at:

#6
#80
#100
JuliaInterop/RCall.jl#513

The PR which is a prerequisite for this to be useful for RCall.jl:

JuliaInterop/RCall.jl#496

@frankier
Copy link
Contributor Author

@schlichtanders

@cjdoris
Copy link
Collaborator

cjdoris commented Nov 30, 2023

I'm reluctant to add hooks like this because it messes with the declarative nature of CondaPkg (note that modern package managers tend not to have hooks like this). I'm not totally ruling it out but it does go against the grain.

The natural way to do what you want would be to have RCall depend directly on CondaPkg (as PythonCall does) and read the Conda env directly from there. If you're using Preferences.jl you can conditionally load CondaPkg so that there is no runtime cost unless the user opts into CondaPkg.

Or you could do the same but with CondaPkg being a weak dependency and using a package extension to enable this behaviour. I'm not sure if this will work (I don't know if a package extension is able to change the behaviour of the parent package's __init__ function).

Alternatively you could create CondaPkgRCall.jl which has a Conda dependency on R and sets the libR preference either in __init__ (I'm not sure how this composes with compile-time preferences) or some other function that the user explicitly calls. Obviously this has downsides.

@frankier
Copy link
Contributor Author

frankier commented Dec 11, 2023

Thanks for explaining this all to me. After thinking it about it a bit more, I'm not sure this would help as much as I thought. I was thinking about the case of running ]conda install in the REPL, and being able to set a preference pointing to a valid R as it is installed, so that it would be available to RCall.jl in subsequent interpreters, but with CondaPkg.jl, R could actually be installed under a variety of circumstances. In some of these circumstances it would be the case that RCall has already be imported, and it is far too late to be setting compile time preferences for the current Julia session.

Having thought about my understanding of the order in which things are initialised, I'm becoming increasingly convinced that "do what PythonCall does" is the only clean option. Unfortunately this would end up with Conda.jl and CondaPkg.jl as dependencies of RCall.jl: so either splitting packages for different cases or introducing a breaking change into RCall.jl. Thanks again for helping me reflect on this. I will close this issue now.

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

2 participants