I agree that there are some missing tools in the Julia package dependency structure. One is conditional modules, partially solved with the Requires package (though not perfectly, especially considering that the conditional code won't be properly included in the precompilation step AFAIK, and there's not a good way to put conditional requirements in the REQUIRE file).
The other is in the version requirement graph. I remember an issue when Immerse required a certain version of Gadfly, which prevented all other packages from accessing recent commits (and broke Plots in the process). In the general case, versions can be shared, but there should ideally be a method to resolve multiple version requirements of a package. In the Plots/UnicodePlots case, this would mean that I could pin the UnicodePlots version for internal Plots calls, but that one could still access the newer version of UnicodePlots directly without using the Pkg commands. There are a ton of subtle issues here (name clashes, etc), which is why I assume the functionality doesn't exist yet. I wonder how feasible it would be if, for non-standard dependency requirements, Julia's package manager automatically added a renamed module into the deps directory, and pointed internal using/import statements to that local copy? This doesn't make any difference for Plots, since the lack of good conditional modules means that I don't even have any of these dependencies in the REQUIRE file. However, it could possibly be a simple alternative for dependency clashes. Disclaimer: I haven't been following 0.5 development closely, so some of these issues may have been improved. On Wed, Jan 27, 2016 at 11:07 AM, max <[email protected]> wrote: > 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 >> >>
