# How to check if a package is installed (in the LOAD\_PATH)?

**URL:** <https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610>\
**Category:** General Usage\
**Tags:** pkg\
**Created:** [November 28, 2019, 8:03am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610 "2019-11-28T08:03:12Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 28, 2019, 8:03am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/1 "2019-11-28T08:03:12Z")

</div>

There has been a similar discussion in [New Pkg: how to check if a package is installed?](https://discourse.julialang.org/t/new-pkg-how-to-check-if-a-package-is-installed/13141) but the OP was satisfied with a solution based on `Pkg.installed()`. This, however, only checks whether `MyPackage` is installed in the active environment.

Is there an easy way to check if `MyPackage` is in (any) one of the environments in the `LOAD_PATH` stack? (in particular the active and the global `v1.3` env)

Clearly, I could parse the respective TOML files manually but I’d like to avoid this if possible.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 28, 2019, 8:08am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/2 "2019-11-28T08:08:32Z")

</div>

Perhaps I should mention that one could in principle do something along the lines of

```julia
try
    @eval import MyPackage
    println("MyPackage is installed")
catch
    println("MyPackage is not installed")
end

```

But this has side effects, isn’t pretty, and also throws warnings like “X doesn’t have MyPackage in it’s dependencies” when used in a package.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [November 28, 2019, 8:40am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/3 "2019-11-28T08:40:59Z")

</div>

Out of curiosity, what is the use case?

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [November 28, 2019, 8:45am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/4 "2019-11-28T08:45:43Z")

</div>

Not public API, but:

```julia
Base.find_package(name::String) !== nothing

```

but it’s safer (still not public API, but atleast you find the correct package) to use

```julia
Base.locate_package(Base.PkgId(uuid::UUID, name::String)) !== nothing

```

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 28, 2019, 8:52am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/5 "2019-11-28T08:52:43Z")

</div>

I’m writing a [WorkshopWizard.jl](https://github.com/crstnbr/WorkshopWizard.jl) that should eventually be a “one command”, OS independent way of installing one of my Julia workshops, that is download the repo, instantiate and precompile everything and check if IJulia is installed.

The question came up in this last part: how to check if IJulia is installed/loadable?

In principle, I could make IJulia a dependency in the Project.toml. But I feel that it really should be installed in the global environment (as it is workshop independent). People will fire up Julia (likely by just clicking on a desktop shortcut) and type `using IJulia; notebook()`, which wouldn’t work if IJulia was only installed in the workshop environment.

Thinking about it again, I could perhaps just temporarily activate the global environment and use `Pkg.installed()`. After all I have to activate it anyways to `add IJulia`. Actually, I could simply `add IJulia` as it will effectively be a no-op if it is already installed.

---

<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:** [November 28, 2019, 8:58am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/6 "2019-11-28T08:58:39Z")

</div>

The intended approach is _declarative_: you say what you project needs, and the resolver and the code loader will take care of it for you. When you are trying to do something _procedural_, it is usually the sign of doing something the wrong way, or missing functionality in `Pkg`.

As for your particular case, I would suggest just committing a manifest, and then relying on `instantiate`.

> [@carstenbauer](#):
>
> But I feel that it really should be installed in the global environment (as it is workshop independent).

I am not sure why that is a concern. If other environments need IJulia, it will just be available, served from the same directory if necessary.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 28, 2019, 9:09am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/7 "2019-11-28T09:09:04Z")

</div>

> [@Tamas\_Papp](#):
>
> As for your particular case, I would suggest just committing a manifest, and then relying on `instantiate` .

As stated above, I am, for everything but IJulia.

> [@Tamas\_Papp](#):
>
> I am not sure why that is a concern. If other environments need IJulia, it will just be available, served from the same directory if necessary.

As I tried to explain above, the reason is (at least) two-fold

- I consider IJulia to be more of a meta package, like BenchmarkTools.jl, Atom.jl/Juno.jl, or Debugger.jl. IMO, it shouldn’t go into a particular project environment but into the global one. (In fact, I’d argue that packages like this are basically the reason for having a global environment in the first place.)
- Pedagogics. Workshop participants are typically beginners. They likely don’t know anything about `git clone`, `instantiate`, `julia --project`, and IJulia. When starting julia the most naive way (clicking on a desktop shortcut or running `julia` in a terminal) they should be able to start the notebook server by `using IJulia; notebook()`. This only works, if IJulia is in the global environment.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 28, 2019, 9:14am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/8 "2019-11-28T09:14:09Z")

</div>

> [@Tamas\_Papp](#):
>
> When you are trying to do something _procedural_ , it is usually the sign of doing something the wrong way, or missing functionality in `Pkg` .

The missing functionality in `Pkg` - I don’t know if it’s really necessary - would be a command to add something to the global environment from within a project environment.

Something in this direction came up on slack the other day. Basically, @davidanthoff was making an argument that perhaps the default environment (the one that is activate when you start julia without extra input) whould not be the “global environment”, that is the one that is always on the `LOAD_PATH` stack unless you remove it. Of course, to not make it a pain to add meta packages like BenchmarkTools.jl to the global environment, this would require new functionality like `add --global BenchmarkTools`.

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [November 28, 2019, 9:35am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/9 "2019-11-28T09:35:12Z")

</div>

What’s the harm in adding IJulia in the workshop environment though?

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 28, 2019, 9:36am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/10 "2019-11-28T09:36:04Z")

</div>

No harm. But IJulia won’t be available globally (which is what I want the WorkshopWizard to do).

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [November 28, 2019, 10:10am UTC](https://discourse.julialang.org/t/how-to-check-if-a-package-is-installed-in-the-load-path/31610/11 "2019-11-28T10:10:12Z")

</div>

What do you mean by “make it available globally”? That it won’t have to be `add`ed to the default environment?

IMO, adding IJulia to your workshop and having people `]add IJulia` in their default environment once they want to use it outside of your workshop is the best approach.
