Post install/update hook about condapkg.jl HOT 3 CLOSED

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.

from condapkg.jl.

@schlichtanders

from condapkg.jl.

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.

from condapkg.jl.