Hello colleagues, On Monday, July 25, 2016 at 4:40:10 PM UTC+2, Stefan Karpinski wrote: > > The difference between the Julia package ecosystem and DLL hell is that > DLLs expose static interfaces and cannot adapt to their environment. If > libA.dll expects on interface from libC.dll and libB.dll expects another, > you're just stuck – you can use libA.dll or libB.dll but not both (unless > you do some crazy stuff with loading multiple copies of libC.dll). Julia > packages are quite a bit more flexible: upon loading, A.jl can introspect > the version and interface of C.jl and adapt to it, so that it works with a > newer or older version correctly. If you want to be able to use A and B at > the same time with a newer versions of C in the scenario you describe, the > solution is to update A so that it works with the newer version of C, and > ideally continues to work the the older version as well. >
Can you give us a good example of situation A.jl and C.jl you described? While i value Stefan's optimism > and ideally continues to work and the experimental/scientific approach > A.jl can introspect the version and interface of C.jl and adapt to it, still i could raise the question: And what if not? And why is it so easy to publish a package creating dependency problems? Why are dependency problems not detected by automatic testing? And what is the recommended way if a package author isn't available? etc. I do not have any answer to the above questions and i expect no simple answers for someone... I agree with Stefan, structure is there to avoid these problems and reasonable forward looking package author can deal with it, but what to do in cases where this has not happened.
