Scripts API "infrastructure" #56
Description
So this is more a suggestion.
We have a set of scripts and programs that help the user maintaining a GoboLinux system.
Some of it is documented fairly well; in other parts there are some shortcomings, in particular on the "meta" level, aka
"what is done here and why".
The first suggestion is that we should eagerly document these missing things. This can happen in the github repository;
in the scripts themselves; and in the wiki. Ideally on all parts. If for some reason we fail to understand something, then perhaps it may be time to work on a replacement, starting with a specification aka "what this should do, how and why". Finding out what things did is also possible - nuc1eon asked hisham and Lucas for some problems or old code. That's also fine, but I think we should prioritize on transitioning into a very documented base system. That should help "onboarding" more contributors in the long run, if the underlying base quality is excellent or good.
The second suggestion is that we should document it in a way as to make any interface "public" and "open", meaning
that people could say "aha, this is the GoboLinux specification 2.0, now I can write php scripts to allow my users on
this or that website to handle GoboLinux specific instructions and do other things" - such as creating a compiled
program and making it available (in this case via PHP), allowing people to, say, do:
InstallPackage https://foo.bar/wget-in-rust-1.0.tar.xz
Or something like that. We could do this for every programming language too. Perhaps someone may then be interested in, say, adding a Rust layer on top of it. Not that this is super-important, but it may be a bit faster, and people may be interested in trying their luck in this regard. And lua-scripts. And so forth.
One advantage of this is that people could more easily contribute code to GoboLinux in general, based on a working and accurate specification; and also making sure that it works. Let me give you an example here.
When I started to write replacements to the GoboLinux scripts in ruby many years ago, I think there is one thing
called GuessProgram (or something like that) that returns the proper GoboLinux name to use. I never understood how it works exactly, so I wasn't able to write a 1:1 replacement in ruby. I kind of just assumed something here which may or may not work (and this is also a reason why I suggested to actually use a simpler scheme, but that's an aside - the more important part is that we can guarantee to have the correct name, described in English).
It would be nice if we could have a description of what it does in simple english (and, if it exists, to perhaps also cross-link this to the wiki, if it is only on the wiki). Because I really suck at understanding shell scripts in general. This is just one example of many more. The idea is to try to have as complete a specification as possible. Deprecations are also fine, just so that we document things too.
One could reason "but there are too few users, so this is not worth the time investment"; well, this is a chicken-egg problem. I think at some point, somewhere, we need to start. People need to be motivated too. I think the better the intrinsic quality is, and the easier it is to contribute to GoboLinux, the more people will contribute too. (On that note, how easy is it to contribute updates to the GoboLinux recipes?)
Now I actually wrote many scripts in ruby that help me compile and install things. I use this on an almost
daily basis. It is not perfect by far, but quite extensive. Right now my projects are no longer available
at rubygems.org (long story) but probably in 2026 they will be available again, at gem.coop then. If this
is the case I'd like to also start a group there for "gobolinux" and begin to write / add code there that
is specific to gobolinux. I'll also add developers who would like to contribute (nuc1eon can coordinate
this if he wants to, I am fine either way - my focus is on trying to add ruby code that can be useful. I
may probably start by using this just as a thin layer over GoboLinux. At a later time I can also tie it
to my ruby-project that handles software, but I will probably retain some kind of compatibility
layer so that these two projects can also function independently. The larger project I maintain here is
not 100% ready for use on a gobolinux system yet; even on a non-gobolinux system it still has some
issues that I'd like to fix, but I am fine releasing it as it is on gem.coop next year - it just has some issues
that I need to solve.)
(By the way, is there a way to email nuc1eon? I managed to lose my old password to my free email provider,
so I had to switch to a new one. So I don't have the old emails right now either. :\ )