How to check if a package is installed (in the LOAD_PATH)?

General Usage
1

There has been a similar discussion in New Pkg: how to check if a package is installed? 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.

1 Like
2

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

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.

3

Out of curiosity, what is the use case?

1 Like
4

Not public API, but:

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

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

Base.locate_package(Base.PkgId(uuid::UUID, name::String)) !== nothing
2 Likes
5

I’m writing a 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.

6

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.

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.

7

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

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

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.

9

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

10

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

11

What do you mean by “make it available globally”? That it won’t have to be added 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.