Thanks for the interesting comments. Two additional thoughts: (1) Certainly the concept of nested dependencies does not imply the actual npm implementation with nested folders on the filesystem. All future package managers interested in nested dependencies will certainly learn from npm's lessons here.
(2) It occurred to me that nothing prevents a Julia package developer today to include a given dependency source in its own source. So for instance to follow-up on the example linked above, Plots.jl could temporarily ship UnicodePlots v0.1.1 in deps/UnicodePlots.jl/... Max On Wednesday, January 27, 2016 at 1:48:12 AM UTC-5, Tomas Lycken wrote: > > Interesting read (or skim, in my case)! > > I think there are some major problems with npm's nested approach too - for > example, file paths tend to become so long that at least Windows has real > troubles handling them (it's not fun to try to get out of a situation where > you can't delete a folder because it's tree of subfolders is too deep, and > not the subfolders because their paths are too long). > > My main takeaway, though, is that our package manager lacks solutions to > two problems that npm solves with nested dependencies inside the project > folder: > > 1 The ability to have different versions of the same package active on the > same machine, and even in the same project's (sub)dependencies. > > 2. The ability to specify dependencies and their versions on a per-project > basis, also for projects that are not modules themselves, allowing you to > check in a file specifying dependencies and then running something like > Pkg.restore() to install everything you need. > > I think this can definitely be done with smaller changes to our ecosystem > than going npm-style all the way, but I also think that these are important > problems that should be considered in a future revamp of our package > manager. > > // T > >
