jbangdev
Pin JBang version (e.g. via `JBANG_DOWNLOAD_VERSION` or `.jbangversion` or `jbang.properties`)
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. https://github.com/enola-dev/enola/issues/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.javaversionor.bazelversionetc.) orjbang.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
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?
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?
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.
first off:
- SDKman allow installing specific version
- jbang wrapper allow to install wrapper
- containers have specific versions
so its not like there aren't options :)
having jbang script download a jar would mess with possible other concurrent executions so I wouldn't be up for that.
I feel this should be "managed" by something else than jbang itself.
its not like you expect maven or gradle to download itself first?
There is an argument to be made that jbang wrapper install should be able to "lock" a jbang version.
if .jbangversion found next to jbang command contains 0.117.0 then we would look for ./.jbang/jbang-0.117.0.jar and fail/redownload if it does not exist.
this file would be created manually or if using jbang wrapper install --version 0.117.0 by default we still want latest jbang be used.
There is an argument to be made that jbang wrapper install should be able to "lock" a jbang version.
Yeah, that would make great sense, to me. Just like e.g. the Maven Wrapper of course respects what version you have pinned in your .mvn/wrapper/maven-wrapper.properties (and gradle-wrapper.properties does the same).
by default we still want latest jbang be used.
Personally I actually would not do that, but I certainly totally respect that YMMV! 😀 Maven and Gradle Wrappers both don't actually work like that either - for good reason.
From where I sit, any external dependency to anything anywhere should be pinned not just with a version number, but with an integrity hash (or e.g. Git revision, if source), preferably Base256Emoji encoded... 😁
by default we still want latest jbang be used.
Personally I actually would not do that, but I certainly totally respect that YMMV! 😀 Maven and Gradle Wrappers both don't actually work like that either - for good reason.
jbang's main usecase is not the same as maven and gradle - the active "take latest by default" ensured most jbang users are using latest and greatest. We don't autoupdate; but we do insist on default install to grab latest and greatest. We know from usage data that there are plenty of users on older specific versions so its obviously not impossible for users to lock down versions ;)
From where I sit, any external dependency to anything anywhere should be pinned not just with a version number, but with an integrity hash (or e.g. Git revision, if source), preferably Base256Emoji encoded... 😁
yes, thats great but try come up with a way to install and ensure that across all the various install mechanics :) I agree sha/checksums would be nice to apply additionally but would still want to use a human readable version number on the filesystem and on the property used to select the version rather than some magic sha.