Is this something that will be addressed with the new package system?
On Monday, July 25, 2016 at 12:05:27 PM UTC-4, Andreas Lobinger wrote: > > 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. > > >
