In the age of TB hard drives, package versioning is what node gets right. Packages can either be added globally or specific versions can be automatically downloaded into a subfolder of the current project directory. I wish Julia would allow projects with local package environments, rather than one big hidden `.julia` folder for everything.
On Sunday, July 24, 2016 at 2:26:29 PM UTC-5, David Anthoff 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] <javascript:> [mailto:[email protected] > <javascript:>] *On Behalf Of *Stefan Karpinski > *Sent:* Saturday, July 23, 2016 11:06 AM > *To:* Julia Users <[email protected] <javascript:>> > *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] > <javascript:>> 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. > > >
