# JuliaPro and Julia Simultaneous Installations: Sensible? Conflicts?

**URL:** <https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258>\
**Category:** General Usage\
**Created:** [February 22, 2018, 5:15pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258 "2018-02-22T17:15:05Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [February 22, 2018, 5:15pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/1 "2018-02-22T17:15:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [February 23, 2018, 11:30am UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/2 "2018-02-23T11:30:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tk3369](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tk3369/32/2824_2.png) [@tk3369](https://discourse.julialang.org/u/tk3369)\
**Post date:** [February 23, 2018, 7:51pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/3 "2018-02-23T19:51:55Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [February 23, 2018, 10:04pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/4 "2018-02-23T22:04:32Z")

</div>

Much slower than lightning.

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [February 23, 2018, 11:17pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/5 "2018-02-23T23:17:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [February 24, 2018, 12:23am UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/6 "2018-02-24T00:23:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [February 24, 2018, 5:02am UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/7 "2018-02-24T05:02:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [February 24, 2018, 4:47pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/8 "2018-02-24T16:47:38Z")

</div>

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

```julia
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"

```

---

<div class="post-metadata">

**Author:** ![iwelch](https://avatars.discourse-cdn.com/v4/letter/i/8c91f0/32.png) [@iwelch](https://discourse.julialang.org/u/iwelch)\
**Post date:** [February 26, 2018, 5:05am UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/9 "2018-02-26T05:05:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [February 26, 2018, 12:06pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/10 "2018-02-26T12:06:06Z")

</div>

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](https://discourse.julialang.org/t/multivariate-ols/9150/13):
>
> 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](https://discourse.julialang.org/t/multivariate-ols/9150/15):
>
> 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].

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [February 26, 2018, 12:39pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/11 "2018-02-26T12:39:34Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 26, 2018, 12:56pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/12 "2018-02-26T12:56:27Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [February 26, 2018, 2:32pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/13 "2018-02-26T14:32:09Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![piever](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/piever/32/1815_2.png) [@piever](https://discourse.julialang.org/u/piever)\
**Post date:** [February 26, 2018, 2:46pm UTC](https://discourse.julialang.org/t/juliapro-and-julia-simultaneous-installations-sensible-conflicts/9258/14 "2018-02-26T14:46:46Z")

</div>

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