(Semi-)automatic installation of missing packages . . .?

I’ve found a few past threads in this forum about automatic installation of missing packages. How to do that now?

The past threads appear to imply that the user is asked whether s/he wants to install the missing package or not. But, I get

$ julia try-packages.jl
ERROR: LoadError: ArgumentError: Package Tables not found in current path.
- Run `import Pkg; Pkg.add("Tables")` to install the Tables package.
Stacktrace:
. . .

from the source code

using Tables

So, at least, I want to recover the old behavior: When using a missing package is encountered, the user will be prompted "Install package XXX? [y/n]: ".

That only happens at the interactive REPL prompt.

I remember watching a JuliaCon talk that introduced a package to auto-install packages automatically upon usage. It required some configuration in the startup.jl file if I remember it correctly.

You may be interested in this package I recently wrote but haven’t registered yet: GitHub - cjdoris/SelfContainedScripts.jl: Julia scripts with dependencies included

It lets you share scripts that have all their dependencies declared inline and automatically installs them for you.

1 Like

Even include("yourscript.jl") fails to prompt the user:

julia> include("try-packages.jl")
ERROR: LoadError: ArgumentError: Package Tables not found in current path.
- Run `import Pkg; Pkg.add("Tables")` to install the Tables package.
. . . .

What’s the difference between writing using Tables on the REPL prompt and including a Julia script that starts with using Tables?

The difference is that the REPL parses the input line and if it contains using or import then it triggers the interactive install if needed. Nothing else triggers this, including include.

I suppose in theory the REPL could look inside the file for you and do the same thing but currently it doesn’t. As far as the REPL is concerned, include is just some function.

Seems to be the way to go!

Perhaps the next step should be that this package be part of the standard Julia distribution . . .

I’m about to publish my little scientific Fortran program. I write supporting scripts in Julia. My headache is how to minimize bothering my users in installing Julia. I expect that 99% of my users don’t know Julia and don’t want to know it. I wrote a little tutorial in my README.md about installing Julia, which is very simple thanks to juliaup.

But then my scripts use some packages. I wrote about how to install missing packages, but that doesn’t help bothering the user.

I could write a Julia script that installs the packages for the user, but that means I have to keep track of the packages I use and keep updating my package-installer script as I update my scripts.

Not exactly that, but relevant: ShareAdd.jl

Thanks for the explanation. That’s really surprising to me. I naïvely thought that include() and copy’n’pasting onto the REPL prompt were equivalent, as #include of the C language.

Put your scripts into a package, and execute Pkg.instantiate() before doing the actual job.

You might find these batch / shell scripts useful.

That is OK if you are sure non of the prospective users of your Fortran program actually use Julia otherwise. I wouldn’t be thankful should somebody’s script litter my default environment.

It doesn’t :slight_smile:

1 Like

I found it pretty convenient to distribute user-facing software (tools at Astronomical Software Tools - Alexander Plavin) by supplementing the code with Project + Manifest files. It only requires the user to call Pkg.instantiate() once after downloading.

As a bonus, distributing the manifest ensures the application continues to work in the future. That you don’t get if packages are “auto-installed” by name, presumably always choosing the latest versions.

I wish it was even more seamless, but the current situation is already fine.
Something like julia --project-auto-install would be nice, that would both activate the project and instantiate its deps if they aren’t instantiated. So that the user can just use this flag always, be it the first run or not.

1 Like

You guys are missing one important point I’ve made. My users wouldn’t be anything like yourselves. They would not care whether their default Julia environment gets extra packages or not. They want to know as little about Julia as possible.

They are not developers. I am not a developer, either! I don’t want to spend too much time to write scaffolding code or config files. I have no idea how to write a package in the first place. Should my 200-line Julia script be a package on its own only because it uses existing packages?

No. There should be a way to make a 200-line Julia script stand-alone. I’d rather write a short script to install all the packages in my users’ default Julia env.

Each time I ask a question regarding managing packages, you guys recommend very organized ways which are way more overkill than my (our) humble needs.

1 Like

The question is, do you want to be sure your script still works in two years or not. If you care about that you must learn about projects and manifests. Not much, just a little bit, as explained here, for example: Working with Julia projects | Julia programming notes

Yeah that’s why I suggested SelfContainedScripts - it basically does this all for you for no effort. It’s exactly targeted at sharing small scripts around and the users not having to worry about Pkg.

1 Like