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
Clearly, I could parse the respective TOML files manually but I’d like to avoid this if possible.
Perhaps I should mention that one could in principle do something along the lines of
@eval import MyPackage
println("MyPackage is installed")
println("MyPackage is not installed")
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.
Out of curiosity, what is the use case?
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
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.
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
As for your particular case, I would suggest just committing a manifest, and then relying on
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 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
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.
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.
What’s the harm in adding IJulia in the workshop environment though?
No harm. But IJulia won’t be available globally (which is what I want the WorkshopWizard to do).
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.