I’m not sure I’m doing this correctly but basically I’m building an “application” not a module. I have a Manifest.toml and Project.toml defined that contain the modules this application uses. So my initial julia file does an:
To ensure that the modules I need are available for the
import commands. My annoyance is that the
Pkg.instantiate() call takes a bit of time to execute. Which is annoying during development, since I’m in an interactive session and the package is already instantiated from the last time “executed” the file.
What I would like to do is check if I’m already instantiated and NOT execute the command in that situation. I was hopeful that I could use
Pkg.installed() for that, but in a clean instance it reports the modules in the base (not sure if there is a better name) environment.
Is there a way to detect the first run vs subsequent runs of a file under Atom/Juno? Or maybe there is a better way to bring in the modules I need?
What I figured right after writing this was doing:
println("Modules are loaded..")
global LOADED = true
which might be using a hammer to crack a nut…
instantiate should be a no-op if everything is already downloaded.
Anyway, you can check if
Base.active_project() == dirname(@__DIR__)
Oh, nice, thanks…I think the delay with instantiate is that it updates the repositories every time it’s called:
Updating registry at `~/.julia/registries/General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
At least for me.
I agree. That takes a bit of time.
What I find useful is to avoid the call to
Pkg.instantiate();. I use it when restarting Julia, with no ill perceived effect at all. I’m not sure if it also works when Julia was running in a different environment before, but it certainly seems to work when Julia was just restarted to the same environment in which it was running before.
Is that expected? When is
Pkg.instantiate(); absolutely required? (@fredrikekre)
When packages are missing (missing as in not downloaded).
activate by itself is quick.
I am wondering why instantiate is not called automatically. Julia does ‘notice’ when instantiate is necessary after all.
I don’t know what the rationale for the people who designed it is, but
instantiate can be a pretty involved computational action, and interrupting in the middle is not a great idea. I wouldn’t want that to happen without explicit request
Yes, it isn’t obvious (to me at least) when the automatic
instantiate should happen. When you start Julia? But maybe you just wanted to do
1+1. When you go into the Pkg REPL? Maybe you just wanted to do a quick
status, or load a package that is downloaded. Etc.
could it be an additional command line startup flag like
--project is? I don’t think doing it automatically is probably very safe, but providing some way to make it easier (as in fewer # steps) could be attractive.
Ah there seems to be a misunderstanding. The scenario I mean seems rather straightforward to me. Namely when I do
The julia may (Iirc) throw an error and complain that I need to run instantiate. In this instance I do not understand why it is not invoked automatically.
Yes, that could be done. I had a proof of concept of something similar to that:
Ahh - this might be nice. Especially when you send something to a julia novice - explaining
instantiate is just one more thing. If they could just
] activate and have instantiation happen, I think that would be useful (and reasonable to have on by default).
I actually asked something very similar on Slack recently because I got into the habit of putting
cd(@__DIR__()); using Pkg; Pkg.activate("."); Pkg.instantiate() at the top of script-type pieces of analysis that need to be reproducible on other people’s (who often aren’t Julia users) machines. It’s all now gone down the Slack memory hole, but the consensus then seemed to be that if people re-run the script,
instantiate is a no-op, so there’s no harm in having it there (@kristoffer.carlsson: correct me if I’m wrong).