JuliaPro and Julia Simultaneous Installations: Sensible? Conflicts?

[iwelch]

I have the standard julia 0.6.2 already installed.

• Does it make sense to install both JuliaPro 0.6.2.1, 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 0.6.2.1, but just 0.6.2 .

regards,

/iaw

[avik]

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.

[tk3369]

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…

[avik]

Much slower than lightning.

[iwelch]

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

[iwelch]

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.

[Elrod]

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

[iwelch]

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

julia PLAIN> Pkg.dir()
"/Users/me/.julia/v0.6"

julia PRO> Pkg.dir()
"/Applications/JuliaPro-0.6.2.1.app/Contents/Resources/pkgs-0.6.2.1/v0.6"

[iwelch]

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.

[Elrod]

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:

Multivariate OLS

of course, nothing comes with everything. (yes, R does come with rootfinders, parallelism, and optimizers in the box.) fortunately, there is one julia, and not ten dialects of julia with newbies having to figure out which one to choose. it is a matter of where to draw the line. I just want julia to be a generally viable alternative in finance, economics, and statistics classes, where the students spend their 10 weeks learning julia, rather than 10 weeks researching package ecosystems for min…

Multivariate OLS

and you draw the line at whatever is needed for But that’s quite arbitrary. MATLAB and Octave come with pretty terrible statistics support but that’s fine. However, if they pulled out the ODE solvers people would rebel because that’s such core functionality. So why wouldn’t you say it’s a core functionality? Because what’s core is personal, except for the extreme basics. Julia is trying to make Base be those extreme basics because otherwise everything is core to some segment of the populatio…

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].

[ChrisRackauckas]

@Elrod

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.

[Tamas_Papp]

@Elrod

JuliaProStatistics, JuliaProEcon, JuliaProPhysics…

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.

[ChrisRackauckas]

@Tamas_Papp

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.

[piever]

+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.