Pin JBang version (e.g. via JBANG_DOWNLOAD_VERSION or .jbangversion or jbang.properties)

[vorburger]

Is your feature request related to a problem? Please describe.

In an ideal perfect world, I would like to be able to "pin" the JBang version in a project to a fixed well known tested stable version.

Currently, the "wrapper" script just downloads the latest it can find. (The JBANG_DOWNLOAD_VERSION env var is only honoured IFF there is no ~/.jbang/bin/jbang.jar already.)

Having such a feature would have avoided e.g. enola-dev/enola#1040 for me.

Describe the solution you'd like

Some sort of mechanism, whatever folks prefer, could be either:

• an environment variable, like JBANG_DOWNLOAD_VERSION
• a .jbangversion (à la .javaversion or .bazelversion etc.) or jbang.properties (à la .mvn/wrapper/maven-wrapper.properties) "version tag" sort of file

Either way, it would have to be implemented so that what it specifies is "always respected"... so it download several versions, and launch the one you want.

Describe alternatives you've considered

I'm currently "emulating" this with a sort of ugly hack:

rm -f ~/.jbang/bin/jbang.jar && JBANG_DOWNLOAD_VERSION=0.122.0 learn/jbang/jbang

[quintesse]

I understand your use-case, but I don't think it's "normal" for applications to just allow multiple versions to be around and make them easily switchable.

If what you want is to "pin" the version (meaning "install it once with a specific version and never change"), why wouldn't the JBANG_DOWNLOAD_VERSION env var do the trick? It's being used in a GitHub action, right? So wouldn't that mean the env var would always be set and it would always download that version?

[vorburger]

I understand your use-case, but I don't think it's "normal" for applications to just allow multiple versions to be around and make them easily switchable.

The "allow multiple versions to be around" aspect is perhaps more of an (optional, I guess) "implementation side effect", and not really what I'm raising here...

If what you want is to "pin" the version (meaning "install it once with a specific version and never change"), why wouldn't the JBANG_DOWNLOAD_VERSION env var do the trick? It's being used in a GitHub action, right? So wouldn't that mean the env var would always be set and it would always download that version?

The GitHub action is a special case. More generally, one would want this kind of versioning thing to "just always work 100% reliably". So e.g. if locally you change branches, while developing, and those branches had different JBang versions, you would want to be confident that "the right one" is always used - and not have to think about it. Just like e.g. if you change the version of the Maven wrapper that you want to use in .mvn/wrapper/maven-wrapper.properties. The JBANG_DOWNLOAD_VERSION currently does not really do that (rather, not entirely, because you have to "remember" to manually rm -f ~/.jbang/bin/jbang.jar).

Does this explanation help, and make sense?

[quintesse]

Does this explanation help, and make sense?

It does, I just think that your use-case is exactly what JBANG_DOWNLOAD_VERSION is meant for. Ideally, like with any regular application, you'd only have a single JBang version installed. Normal users should never have to use the env var. Being able to even set the version to download was created for highly specific circumstances, for example, testing.

So in your case I could imagine saying "hey people, let's stick with JBang 0.122 for now until the issue has been fixed, if you've already updated to 0.123, this is the way to go back ...."

So given that this not being entirely trivial to implement I'm not sure if it's worth the effort when in 99.9% of the cases people will only ever have a single JBang version on their system. But let's see what @maxandersen thinks.