Generic "yunohost service add"?

Contribute Room Apps packaging
1

I’m working on a generic template for all apps.
e.g.: Rename ynh_script_progression with app names to generic ones using $app for the app name, see: Updates by jedie · Pull Request #14 · YunoHost-Apps/django_example_ynh · GitHub

But there is the yunohost service add in install. I change this to a generic expression with:

grafik
grafik881×75 13.5 KB

see: Updates by jedie · Pull Request #14 · YunoHost-Apps/django_example_ynh · GitHub

But is there a better one? Why not use "description" from manifest.json ?
Is it possible to use values from manifest.json with the current code base?

2

Hmyeah I think if you want to make it generic, you may use I-dont-recall-which-helper to parse the manifest and extract the description. In a more general sense, some apps have multiple services associated to them (eg mastodon) so it makes sense to have a specific description for every service but that’s boring to implement and maintain the sync between scripts. Alternatively I think Yunohost fallbacks to the description in the systemd conf if none is provided in yunohost service add

3

It’s ynh_read_manifest : App helpers | Yunohost Documentation

Correct! yunohost/service.py at dev · YunoHost/yunohost (github.com)

4

Perfect… Then i just remove them: Update to django-yunohost-integration==0.4.0rc1 and remove own valida… by jedie · Pull Request #16 · YunoHost-Apps/django_example_ynh · GitHub

5

Sadly, it’s not a really good idea:

image
image1330×95 29.4 KB

https://ci-apps-dev.yunohost.org/ci/job/2898

6

Hm in that case the package_linter should be smarter and maybe check if there’s a description in the systemd conf too idk

7

Ah that not the linter, it’s Yunohost core, let me check

8

Ah so the core does fallback to the description in the systemd conf, but the issue lie in the fact that you scripts are calling yunohost service add before ynh_add_systemd_config

(If you ask me, that thing about yunohost service add should be done automatically or using an option inside ynh_add_systemd_config but i don’t know if that’s worth changing the practice instead of working on packaging v2 / v3 …)