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.
On Sun, Jul 24, 2016 at 3:26 PM, David Anthoff <[email protected]> wrote: > The deeper problem though is: what if I want to use all the currently > installed packages at the same time, but don’t want the downgraded versions > of them? Say I want to use package A and B, and both have a dependency on > C, but A requires some older version of C, and that prevents me from > getting the latest version of B. > > > > In some way the situation is a little like DDL hell on Windows in the > early 90s: we can only ever have one version of a dependency installed and > loaded at the same time in julia right now. I guess one way to “solve” this > would be to start adding new versions of packages whenever there is a > breaking change, i.e. when C introduced a breaking change it could have > registered a new version C2. Terrible, of course, but that is what happened > on Windows for things like the MS C runtime… > > > > Are there any thoughts around this, how this could be solved for julia? My > guess is that these situations will only happen more often as the package > eco-systems grows… > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Stefan Karpinski > *Sent:* Saturday, July 23, 2016 11:06 AM > *To:* Julia Users <[email protected]> > *Subject:* Re: [julia-users] Re: Which package downgrades other packages? > > > > The way to do this would be to compute which packages' removal would allow > another package to be upgraded. > > > > On Sat, Jul 23, 2016 at 1:59 PM, Tony Kelman <[email protected]> wrote: > > Part of the issue here is dependency resolution is a global feasibility > problem, each package imposes a subset of constraints. So you can identify > active / free constraints at a solution, but it can be hard to assign blame > to a single package in general. > > > > > On Saturday, July 23, 2016 at 7:37:50 AM UTC-7, Chris Rackauckas wrote: > > Another +1. When Optim.jl tagged v0.5, it took me too long find out it was > responsible for rolling back a few of my packages, causing some tests to > break (especially since I didn't have it master checked out for it, so I > wasn't expecting it to really change! I only tracked it down because of the > julia-users announcement). That's not Optim's fault, but an issue with the > package system for not making it explicit why it was occurring (at least it > didn't a month ago?). I think Pkg.update() tells you when a package is > rolled back, but not why. > > > > IIRC, I was really hoping that Pkg.status() would tell me whenever a > package was not at its highest version due to another package, and tell > me which package was doing that. For example, > > > > -CoolPkg 0.1 (Rolled back due to AwesomeFoo) > > > Then it would be easy to see where I should checkout master, find how to > make them work together, and submit a pull request! But I don't know if > that would be difficult to implement. > > On Friday, July 22, 2016 at 7:24:30 PM UTC-7, Tony Kelman wrote: > > Maybe a useful function to write and submit to PkgDev would be go through > all installed packages, check the METADATA requires file for all the > installed versions and display a list of upper-bounded dependencies and > which package is responsible for each. A little bit of code might go a long > way in making this more discoverable. > > >
