Python required it when you use the os library. When you write for example
Var = os.getenv('VAR", “”)
Yes you retrieve json_property from the CLI with configure-module and you save the value to
ENVIRONNEMENT_VAR
var = data.get(“json_property”,“default-value_if_not_exist”)
agent.set_env(“ENVIRONMENT_VAR”, var)
this part is not yet clear to me.
And
docker.io/roundcube/roundcubemail:1.6.4-apache vs ${ROUNDCUBEMAIL_IMAGE}
When you build the module we keep the image name, we do uppercase and concatenate _IMAGE
then we store it in .config/state/environment
It is a environment var name that contains docker.io/roundcube/roundcubemail:1.6.4-apache
so basically, i should rename that part to this:
the same name that is given to the Image under
Build.sh here:
Yes in uppercase. You can verify the name of the var when you install the module by doing cat ~/.config/state/environment
On A seprate Note to the Devs,
I understand every developer has their Own approach to matters on the Module Development,
but considering this is a new platform that would require developers and the community to implement modules for it in the near future,
wouldn’t it be a great Idea to Have a Systematic, coherent format of handling Modules config values, especially for the common Items within the Modules,.
this is because, these Modules provide a Base reference for module Development, and Any discrepancies causes someone to wonder what exactl was happeneing.
eg, in certain Modules, a Traefik file has been added under configure, which handles traefik related routing, in other modules, this has been implemented within configure filename.
Similalrly, i think we need to reconstitute the Kickstart Module with alot more details and folder structure that are necessary for any basic module to be completely funcion.
eg if we are using env to store defaults , configure for values to be done from the interface, and traefik for routing etc, lets have these pre emptive within the Kickstart module, that way it makes it alot easier for future developers.
I might have figured out something while attempting to build a module, but others coming in later should get it easier out of the learnings from previous attempts like Myself.
I hope you consider my thought and hope youve understood exactly what i mean, could we then kindly work on imporving the Kickstart Module, with the additional files, and proper seprations for where necessary to make future Module Development abit more easier to would be module contributors.
Reading the project paperless and more particulary the docker-compose you have at least a web, redis and a mysql container with your paperless container that should be running at the same time in a pod
running that throws the error shown.
Also, how come, for every instance of the module that i install, the module id goes like 1,2,3,4
een if previous versions of the module have been removed, it will continue from where the last module was installed, should that be the case.
Honestly for a web app the kick start is quite complete but for a more complicated usage It cannot fit you need. It is just a start mostly to configure the whole webstack part fir the UI
The webpack/UI stack is the most difficult side to take in hand
so does that mean i need to also add, seprately a Mysql container and a redis container as well into the Module to make them work.
i think i was under the assumption that the paperless container came with those running within it.
If your module is rootless then
/home/module_id/.config/state/environment
RTFM all the time even if myself I admit I start too much time by reading/writing code then I read documentation
Yes you have choosen a big project for starting a module
The first set of Modules from the community are essentially going to be from:
and from what i can see with my attempt of a “simple non complicated” module, i am afraid the Kickstart is not going to suffice for 98% of those modules.
then we go to the more complex modules, which were never built as Module, but only HOWTO instaructions fro NS7, those would defintely have to be compiled into modules this time around, others have way too many moving parts.
eg, TacticalRMM has both Tactical and MEshcentral within It running as One. atleast NS8 has grafana baked in.
this is defintely true, especially on the settings Page for the Kickstart, it would be fantastic to provide pre-defined settings common to most apps, and those that could be comment able, with defined comments to enable or disable them.
then we could also have the same linkage between configure and read configure in relation to those values.
i think with these improvements, the Kickstart Module would be ready for any type of Module someone would throw at it.
i understand it would/ might be a lot of work to define those in the Kickstart, but it would be Worthwhile in the long run for the community and community contributors.
Well as a developer mind, you won’t accept default value, it is not possible to make something that it will fit your need, instead you have to read code and understand what you have/need to do inside your module. Front of a Cliff, a developer will climb it.
make something that will cover 98% of your need is not possible but I understand you . Che Guevara has said one day : Let’s be realistic, let’s demand the impossible
Saying that if you have proposals to kickstart, please make a pull request with your changes and we could talk of it
At a time I thought to make in settings the full web page to configure at least traefik, I think it could be a good start. For mattermost, collabora I think we just have traefik to configure
Will Look Into it, and if possible submit the necessary proposal improvements as PR for the Kickstart, Hopefully if i introduce Unnecessary bugs or issues into it, you’ll help me look into them and improve, overall, everyone benefits.
sure, this would be a good start, but wont that take up alot of dev time, considering we still have a release to achieve. or is this just on the kickstart.
but lets be honest, without defined best practices, every developer will do their own thing, so long as it works, but to the detriment of future sustainability,
Imagine if i build over 20 modules, that end becoming mission critical for most of the users, then for whatever reason, i am no longer available to maintain, but when you look into the module for improvements, you can understand half of what i was doing, but it work…
then you end spending a huge chunk of your time re-writing or refactoring the module,
wouldn’t it have been easier when it could have been avoided ealier on by defined best practises and well informed folder and file structures for module devs to follow.
for this, before to start to code, go to the github repository and begin by reading code, if you need a pod example, I think ns8-roundcubemail is a good example
I’m pushing a new procedure of entering the context of a rootless module.
runagent -m mymodule1 bash -l
Where in the past we did
ssh mymodule1@localhost
runagent bash -l
Once you get the Bash shell (which chdirs to the state/ directory) you can do
cat environment | grep IMAGE
Or
env | grep IMAGE
In a single line:
runagent -m mymodule1 env | grep IMAGE
2 Likes
It should be visible under the launcher menu (top right screen corner) 
. Accessible with Ctrl + SHIFT + A shortcut.
The Software Center has a scope limited to applications coming from the configured repositories.
1 Like