Well, I can’t be very specific, but I will try to provide a more precise idea of what I’d like to achieve.
Let’s assume that the SCI
package looks like
module SCI
export fun1,fun2
fun1(x) = x
fun2(x) = x^2
end
this package should work standalone, and should perform only specific computations.
Now I want to send computations requests, specifically the ones that SCI
performs, from outside of julia.
I found my way to do this using sockets and other stuff. That’s where COM
pops up (though I can’t make a MWE out of this), to translate a request from the outside world to something SCI
can do
module COM
using SCI
# function to initialize a container
init_container() = []
# function to read a message from a pipe, assume it always return `:fun1` here
read_message() = :fun1
# function to check if instruction is authorized
# function doing something based on the message received
function compute(container,msg)
if msg == :fun1
push!(container,fun1(rand))
else if msg ==:fun2
push!(container,fun2(rand))
end
return container
end
end
# Load COM+SCI utilities
using COM
container = init_container()
msg = read_message()
container = compute(container,msg)
Obviously, compute
needs to be somehow aware of SCI
otherwise what’s the point.
I don’t know if it makes much of a difference, but a big aspect of the COM/SCI
interaction, maybe something that I forgot to clearly state before, is that when I run COM
, I only run it with a single SCI
package at once.
So for instance if I have SCI
and SCI2
I will start a task using COM+SCI
and another task for COM+SCI2
.
I NEVER have COM+SCI+SCI2
running at the same time.
Because of the current inter-dependency due to compute
and other functionalities of the same kind, my COM
should be called COM_SCI
.
To get rid of SCI
, I tried to use a global constant pointing towards the right SCI
package e.g. CURRSCI = SCI
and do
using SCI
global const CURRSCI = SCI
using COM
# where all SCI defined functions are now called with CURRSCI.funX ...
...
but that doesn’t work, CURRSCI
is not known inside COM
. I also tried with import ..CURRSCI
but it seems to fail too.
Long story short, I can’t figure how to share just enough information so that I do not have to maintain two (or more) versions of my COM
package.
I tried the Requires
approach and the patch strategy you provided. This results in a modification of SCI
as
module SCI
using Requires
...
function __init__()
@require COM="<some_id>" include("COMsetup.jl")
end
where COMsetup
contains patches for e.g. init_container
,compute
and others, but that fails too…
Frankly, I’m lost there, I do not see how to organize this in a versatile enough manner.
Sorry for the inconvenience if I’m too vague, but it’s quite unclear in my mind how to handle this.