I am thinking of changing how a user can set environment variables when installing a rockon.
Currently all env vars have to be entered by the user, even if they are optional or have a default value that the user is happy with.
My proposal is to introduce two additional concepts: optional vars and vars with a default value. This would be in addition to required vas that are currently used.
How would this look like?
The required vars would stay as is. If a default value would be defined, it is displayed.
The fields of optional/default vars would start off disabled. Beside them would be unchecked checkboxes. This state would denote that they should not be set. Or in the case of default vars, the default value would be used.
When the user checks the checkbox, the field would become enabled. Now the user can input a value.
Why the checkbox?
Because it helps us to understand the difference between an unset variable and a blank valued variable.
In the case of default vars, the default value would set instead.
Changes to the rockon json are denoted by **:
{
"description": "<Detailed description. Eg: Login username for Syncthing UI>",
"label": "Web-UI username",
(optional)"index": <integer: 1 or above. order of this environment variable, if relevant>,
** (optional)"default_value": <string: can also be an empty string>,
** (optional)"required": <bool: true, variable is required to to be filled out by the user; false, variable is optional. Default true>
}
I think this has been brought up in the past (required vs. optional variables), which to me seems like a good idea, especially for some Rockon candidates with images that have a lot of optional variables that could be defined (or not, depending on use case).
I will let @Flox provide his input, since he has been working on restructuring the Rockons over time. I suspect, given the limited dev capacity we currently have, entertaining this will have to wait until after we have the next stable release (soon, hopefully). While being discussed here, would you care for opening this topic also as a feature request on the corresponding github repository, referencing this post?
I too think it’s a great idea, if not a necessary one! And you are correct about the fact that it has been brought up in the past as well. We actually already have a series of issues to keep track of these few points:
@aremiaskfa, I pretty much agree with all your points: the only reason it hasn’t been implemented yet is unfortunately related to our current focus on getting the next Stable release out and fixing breaking bugs reported along the way. Once we do have some more time to spend on enhancements such as these, I personally think it should be rather high on the to-do list. I would thus think of it as a matter of time more than anything else.
Speaking of which, let us know if you are game in giving a try at this yourself as we’re all here if you are seeking inputs/pointers on how to attack this.
Ok great. I have begun milling around in code to support this feature.
Since the unpackerr rockon offers so many optional environment variables, I think it would be best to first land this feature.
I am sure that it will take a while before I find the time to implement this. But showcasing and discussing UI/UX prototypes we can do even before the implementation starts.
There is progress on this front.
Comments from users are always welcome, since they/we will have to use it
Is the UI clear in what it’s trying to convey?
.