What is jbang: script runner vs package manager #269
Replies: 4 comments 2 replies
-
wow - excellent write up, good points and you hit on something I haven't actually fully settled on yet. Let my try and articulate where I think jbang is heading. I do believe jbang is more a script/app runner than a package manager; but I do actually see a need for it to be a bit more smart about how it manages its cache. Like, I could imagine doing something like Go with its GOPATH and a fairly rigid structure beneath it; bit for slightly different reasons. The current mechanism works fairly well when we are dealing with single file scripts on the file system; it does fall apart though as On top is jbang edit on http resources when we are adding multiple source and/or resource files. If we had something like GOPATH with well defined source / build-results locations this could work....but I definitely don't want to enforce users to put their scripts into a GOPATH location to be able to run them....so there is some balancing and user experience to figure out here. About renaming of commands - now that you pointed it out the commands can be confusing dependent on what perspective user has I think I'll at least start of by seeing if can get the commands categorized to clearly separate them. About build - the main usecase it exists is to enable having the script precompiled in a dockerfile rather than paying that price on every run. good points all around... |
Beta Was this translation helpful? Give feedback.
-
Then the approach is scrip runner + making buil/cache explicit. * I like describe over info, becuase given cache is a noun is more natural that the next word is a verb.
Then, another question comes to me. When does jbang become a full-fledged build solution? |
Beta Was this translation helpful? Give feedback.
-
I did an attempt of grouping at #273 feedback welcome - my brain keeps reshuffling them ;) You point about |
Beta Was this translation helpful? Give feedback.
-
for those who finds this thread jbang now has a |
Beta Was this translation helpful? Give feedback.
-
Everything is based on personal experience and is open to debate
Formalizing my comment #265 (comment).
In short, I see jbang providing both features of a "script runner" and "package manager" (for lack of better names).
I find some commands match one approach and others the other, and to me at least, becomes a bit confusing.
Context
For example, when running
jbang
for the first time, one is greeted with:run
is obvious at first glance, but then you seebuild
and wonder:edit
recompiles automatically? Does it modify the source or the built version?init
have anything to do withbuild
?Being familiar with Java and similar tools (kscript) work, is not a big thing.
And won't deny some of the current problems can be fixed with some rewording.
But I can see some people confused at first which may affect the first experiences with jbang, and some inconsistencies crawling here and there.
To sum up, I think having clear high-level goals/vision about the project helps:
Only for thoses I think it makes sense to define what jbang wants to be. This could change with time, but at least would also identify and better communicate major versions and breaking changes.
If it is to be a script runner
The process of compilation and caching should be made transparent and only visible for diagnostic purposes (e.g. --verbose).
This is a use case for pure scripting like usage in CI.
Using the original https://github.com/jbangdev/jbang/issues/265[issue] as example, as a user if my only options are to run scripts I don't care what's under-the-hood. I trust jbang will take care of the details.
If for some reason I want to see the jar, I can only imagine that to diagnose some issue, so it's not a common case that should be provided ootb.
My approach would be to show the jar path during
run
.That means that:
build
command makes no sense. If the purpouse is to provide a pre-check and manage dependencies this should be make explicit and the command renamed.If it is to be a package manager
The process of compiling, installing and even dependencies handling could be explicit to the user similarly to how is made now.
The "binary" becomes an entity on its own, and it makes sense the users may want to deal with them once the script is installed. Here,
run
is just and allias toinstall + run
, andbuild
should be renamed toinstall
.You see here the commands make sense and is easier to explain what they do in a consistent way.
The goal would be making jbang more like how Go or "npm install -g" work.
This includes the same use cases as scripting but expands it so that jbang can be used more collaborate.
We all have those scripts that we use to automate things. This makes easier to install then and use them as any normal tool, specially with native compilation in the horizon.
If jbang is to evolve in this direction:
build
should be renamed toinstall
. I think this conveys a better meaning and removes ambiguity with other commands, specially if help is reordered and reworded.Current
edit
option could be revisited. In both scenarios I find it confusing, but specially here. It creates extra files that then you cannot clean and do not belong to either the cache or the source path.alias
make a lot more sense and should be a paramater of theinstall
command (I admit I don't fully unsterstant the alias use case, so could be wrong here..as in all the rest 😄).The meaning of "cache" changes however to be "local or installation area", but this is a naming thing.
Could be interesting to consider if we want installed scripts to be available by default in the PATH.
Once installed, it makes sense to be able to list/describe/uninstall/edit installed scripts and run them without referencing the original script. And the original name of the script becomes an identifier used to references the binary.
So
jbang run
does not required to have access to the original script, and to simplify usage, the name could be the script without file extension.Original source(s) would need to be installed alongside the jars, so it's clear what is being edited. An option to "cat" the script in the console would make sense.
edit
becomes consistent in that only installed scripts can be edited.It allows modifyng the installed source and should take care of automatically updating the cache.
Using the original https://github.com/jbangdev/jbang/issues/265[issue] as example, this would fall under options of the
cache
command.The command should provide options to list, describe, uninstall and edit installed scripts.
This may required adding extra metadata.
Note that I am avoiding discussing things like script versioning or intra-dependency. I assume that's out of scope in any scenario. That's why I don't like the name "package manager" :% Implies many things.
Beta Was this translation helpful? Give feedback.
All reactions