JuliaPro uses its own package directory, and so can live simultaneously with the open source julia build. The main difference is that the in-built packages in JuliaPro are pinned, and so cannot be upgraded. New packages may be installed, but only if they are version compatible with the existing packages.
Are you sure about the different directories and thus permissible multi-installs?
on macOS, I think both Julia 0.6.2 and JuliaPro 0.6.2.1 share the ~/.julia/v0.6 directory. or is there another directory that I am not seeing?
Suggestion: The command line startup notices of plain and Pro seem to be exactly the same. They may be the same executable, but if they use different packages, something that indicates that they are different, even if it is only how Pkg behaves, would be good.
I haven’t used JuliaPro in a while. When I did, I ran into a lot of problems with version conflicts.
In particular, I remember wanting to use the latest Optim.jl, which had just undergone an API change – but I was stuck on an old version.
I head this got better as we moved further from Julia 0.5 (ie, almost all the packages have caught up to 0.6 now). I didn’t know until this thread that they’ve actually pinned the packages.
A little off topic, but:
Couldn’t JuliaPro solve some of these issues? That is, JuliaProStatistics, JuliaProEcon, JuliaProPhysics…
Packages tailored towards fields, so that they can be relatively lightweight, and cover basics that people in different fields need? People teaching classes can easily direct their students to JuliaPro[field].
JuliaPro is tied to JuliaComputing and its brand. But some idea of “Julia distributions” for specific domains is interesting and something I proposed awhile back when the whole standard library idea was starting up. Maybe it’s time to revisit it.
Yeah, that’s why I did DifferenitalEquations.jl this way. Instead of letting people sift through (currently) 59 individual package documentations, document them all together. It also forces you to design an API that’s cohesive. JuliaOpt is like this through JuMP. I know that JuliaStats has been resistant to metapackages though. There’s some old Google Groups discussions that can be dug up on it.
+100 to this! The current strategy of many small packages is good for developers but some users really get lost: post 1.0 it’ll be crucial to do some meta packages with simple names to simply import and reexport most things that are relevant in a given field. I would also like to eventually see Stats.jl with StatsBase, StatsFuns, GLM , MixedModels and friends.