Automatically re-fetch JARs when missing

[rads]

In bbin 0.2.0 we're going to use the ~/.cache/babashka/bbin/jars directory to store JARs. This means the directory should be able to be deleted without breaking anything.

Right now the JARs only get downloaded when you run bbin install. I'd like to change this so the JAR will be re-fetched automatically if it's missing. This would match the behavior of the tools.deps-based installation methods.

This requires changing the JAR storage to include a hash to ensure the JAR content doesn't change if it's re-fetched after the initial installation.

[borkdude]

This requires changing the JAR storage to include a hash to ensure the JAR content doesn't change if it's re-fetched after the initial installation.

Can you elaborate on this? What if it did change?

[rads]

@borkdude: My intent is that when you install a script with bbin install, the code for the script won't change after installation unless you do another bbin install (or in the future, bbin upgrade). Consider the following command:

bbin install --as hop https://github.com/gethop-dev/hop-cli/releases/latest/download/hop-cli.jar

It would be surprising if the hop command pulled down a new version of Hop whenever the ~/.cache directory was cleared. This directory may be cleared simply due to restoring from a backup.

An alternative solution could be to move the JARs to a non-cache directory and not support re-downloading the JARs. That said, I also want to make all scripts self-contained. In other words, I want to be able to copy my files in ~/.local/bin to another machine and run them without bbin installed. JAR scripts are the only exception to this right now since they will be broken without the ~/.cache/babashka/bbin/jars being set up correctly.

[rads]

Thinking some more about the Hop example above... If the cache is cleared and the hop-cli.jar is different than one it was installed with, I would personally prefer to prompt the user and ask if they want to re-download. If the hash is the same we don't have to prompt them.

[borkdude]

It would be surprising if the hop command pulled down a new version of Hop whenever the ~/.cache directory was cleared

Why would this be surprising? It is what I would expect. This is also how .m2 etc work, right?

[rads]

That's a good point about ~/.m2. I'm fine with skipping the hashing part to match Maven's behavior. Maven tools.deps also prints a message when downloading a new version. We could add this to the bbin scripts as well to let the user know when a new JAR is being downloaded.

[borkdude]

Sounds good!