JuliaPro and Julia Simultaneous Installations: Sensible? Conflicts?

I have the standard julia 0.6.2 already installed.

  • Does it make sense to install both JuliaPro, or is it identical to standard Julia but with packages already in the box, plus some extras?

  • if it makes sense, can having both JuliaPlain and JuliaPro installed create conflicts? I see that JuliaPlain uses .julia/v0.6. Does JuliaPro use the same directory, or its own directory?

  • on startup, the JuliaPro message does not seem to say, but just 0.6.2 .



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.

1 Like

How often does JuliaPro get updates? I imagine the we are moving in such a lightening speed and it’s really important to keep up…

Much slower than lightning.


thunder. on my other thread, I am wondering why both Julia and JuliaPro fail to get me to a working combination of (Missing) packages.

Are you sure about the different directories and thus permissible multi-installs?

on macOS, I think both Julia 0.6.2 and JuliaPro 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.

Use Pkg.dir("packagename") to find the directory.
Pkg.free("packagename") should also unpin it.

1 Like

indeed. so this was not my problem. somehow, JuliaPro still loads an incorrect combination of packages.

julia PLAIN> Pkg.dir()

julia PRO> Pkg.dir()

I am rather reluctant to unpin in JuliaPro. after all, its point is stability, and once I touch it, who knows what I can break.

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.

I really hope that the package system gets to the point that one can do this with a plain vanilla Julia installation + installing MetaPackageForField.

Any “batteries included” distribution of Julia + packages gets obsolete very quickly.


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.