[01:18:55]
<miro5001> > <@m606:matrix.org> Thanks for explaining. But now I don't get what you said earlier that you would rather consider avoiding `ynh_app_setting_set` for redis databases
Suppose your app gets redis_db = 1
Save it as setting
Make a backup (that includes redis_db = 1)
Remove the app
Install another app that will use the first empty redis db, which is 1
Try to restore the first app, but there is already redis_db = 1 in use by the second app. The restored app will be using a non empty db, which will break something at some point.
Letting yunohost manage redis_db is the best way.
I only faced difficulties when the app required 2 different db's and in the install script if you ask for the first free db 2 times, you well get the same one since the first one has not been used by the app (or ask for it after running the first service). I used the redis_db_lock / redis_db_unlock hack to have the script organised and make it easier to read
[01:42:55]
<Yunohost Git/Infra notifications> [apps_tools] DeMiro5001 [commented](https://github.com/YunoHost/apps_tools/pull/18#issuecomment-2777354895) on [issue #18](https://github.com/YunoHost/apps_tools/pull/18) Simpler READMEs: The upstream code link has been removed? I use it very frequently. Can it be as an icon (github, gitlab, others)
[01:43:08]
<m606> Thanks, so if I got it well, that would give something like:
- install: create 2 redis db (using the lock hack), hydrate app config template with those values.
- upgrade: get redis db ID from OLD app config file, hydrate NEW app config template with those values.
- restore: create 2 redis db and set these new IDs instead of old ones using`ynh_replace` in the app config file to restore
- remove: get redis db ID from app config file & `ynh_redis_remove_db` them
[01:49:10]
<Yunohost Git/Infra notifications> [apps_tools] alexAubin [commented](https://github.com/YunoHost/apps_tools/pull/18#issuecomment-2777360153) on [issue #18](https://github.com/YunoHost/apps_tools/pull/18) Simpler READMEs: [2025-04-04-034852_538x93_scrot](https://github.com/user-attachments/assets/1b1ebfb9-df6a-48e0-b70d-ec8de6014535)
[01:49:22]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 [commented](https://github.com/YunoHost/apps_tools/pull/18#issuecomment-2777360309) on [issue #18](https://github.com/YunoHost/apps_tools/pull/18) Simpler READMEs: > The upstream code link has been removed? I use it very frequently. Can it be as an icon (github, gitlab, others) No i...
[04:09:45]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 opened [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[04:12:47]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 [commented](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2028057175) on pull request #18 Simpler READMEs: [Yet another proposal](https://github.com/YunoHost/apps_tools/pull/27) with: - bigger app logo - centered top section -...
[04:23:09]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[04:24:26]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[04:24:46]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[04:26:03]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited a [comment](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2028057175) on pull request #18 Simpler READMEs: [Yet another proposal](https://github.com/YunoHost/apps_tools/pull/27) with: - bigger app logo - centered top section -...
[04:26:13]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited a [comment](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2028057175) on pull request #18 Simpler READMEs: [Yet another proposal](https://github.com/YunoHost/apps_tools/pull/27) with: - bigger app logo - centered top section -...
[04:26:18]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 [commented](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2028068482) on pull request #18 Simpler READMEs: Maybe CI badge should go in Developper section ?
[04:32:49]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[04:38:15]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[09:24:50]
<miro5001> > <@m606:matrix.org> Thanks, so if I got it well, that would give something like:
> - install: create 2 redis db (using the lock hack), hydrate app config template with those values.
> - upgrade: get redis db ID from OLD app config file, hydrate NEW app config template with those values.
> - restore: create 2 redis db and replace values using`ynh_replace` in the app config file to restore
> - remove: get redis db ID from app config file & `ynh_redis_remove_db` them
ynh_config_add can do it, unless the user has manually modified it
[09:32:50]
<miro5001> Is there a "postfix admin" app?
[09:50:37]
<miro5001> Oh, there is
[12:41:43]
<m606> > <@miro5001:matrix.org> ynh_config_add can do it, unless the user has manually modified it
not sure which step(s) you are referring to ?
[12:57:00]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[12:57:48]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 edited [pull request #27](https://github.com/YunoHost/apps_tools/pull/27): Yet another "simpler readme" design proposal
[15:01:10]
<miro5001> > <@m606:matrix.org> not sure which step(s) you are referring to ?
I mean in the restore script, after restoring install_dir
[15:03:43]
<Aleks (he/him/il/lui)> MFW it's 5PM (or is it 6PM now?) on Friday https://www.youtube.com/watch?v=bfB38RlXRbI
[15:07:56]
<Aleks (he/him/il/lui)> >[Apps Update Levels (weekly)] [🔴 Down] exit-code (exited 101)
🙀
[15:40:04]
<m606> > <@miro5001:matrix.org> ynh_config_add can do it, unless the user has manually modified it
yes so in this case I don't really see why the user would want change redis_db IDs...
[15:50:04]
<m606> > <@Alekswag:matrix.org> i'd say config should go in `$install_dir`
so eventually, that app is to be installed via pip (no source files to download/extract), i.e. by default there would be nothing in `$install_dir` unless we choose to - i could put there `.venv` & `cache` folders as well as `pretix.cfg`. It makes more sense to have those there, rather than in `$data_dir`, right ?
[15:53:02]
<Aleks (he/him/il/lui)> hmmmyeah imho data_dir should be ... just data
[15:53:08]
<Aleks (he/him/il/lui)> but that's debatable
[15:53:26]
<Aleks (he/him/il/lui)> cache and venv / node_modules etc typically go in install_dir
[15:53:31]
<Aleks (he/him/il/lui)> and configs
[15:55:42]
<m606> > <@Alekswag:matrix.org> hmmmyeah imho data_dir should be ... just data
yes ok that makes sense to me, like `/home` folder in linux
[15:56:33]
<Aleks (he/him/il/lui)> yeah install_dir is pretty much the home of the app
[15:59:57]
<m606> but if I get you correctly, it is more out of "care for meaningful structure", than actual related feature at the moment?
[16:01:00]
<m606> though I can think of a use for it - like if you want to make a quick backup on little storage place, you may want to focus on `$data_dir` only rather than backing up all app files
[16:01:21]
<Aleks (he/him/il/lui)> not sure what you mean ?
[16:05:13]
<m606> from what you say I feel I could either put everything in $install_dir or $data_dir and that would probably not make any YNH feature fail so far?
Although I get your point about home for app vs. home for data and one immediate use for that distinction would be if an admin wants to make a quick backup from his/her instance (with maybe some constraints like limited storage space), he/she could just backup `$data_dir` and would have thus backed up the most important.
[16:06:15]
<m606> though with that logic in mind, maybe I should put user pretix.cfg (app config file potentially modified by user) in `$data_dir`
[16:06:37]
<m606> and put .venv & cache in `$install_dir`
[16:07:35]
<m606> basically my debate is only on the config file )
[16:09:19]
<m606> @miro5001:matrix.org Would you remember what is the .bashrc line for here ? https://github.com/YunoHost-Apps/indico_ynh/blob/1a4be95bcfa0aac73252e648d3d5d692cc0c4bd9/scripts/install#L64
[16:10:17]
<Aleks (he/him/il/lui)> yeaaaaaaa well yeah you could argue that in some case, the config is important too ... but the initial discussion was about /etc/$app/some.conf vs putting the conf in $install_dir, for which imho it's better to put it in $install_dir, at least because that's the defacto standard right now, and because you don't really need to think about backing up the conf from /etc/$app/some.conf in the backup/restore script because the backup script typically backups $install_dir anyway
[16:11:29]
<m606> > <@Alekswag:matrix.org> yeaaaaaaa well yeah you could argue that in some case, the config is important too ... but the initial discussion was about /etc/$app/some.conf vs putting the conf in $install_dir, for which imho it's better to put it in $install_dir, at least because that's the defacto standard right now, and because you don't really need to think about backing up the conf from /etc/$app/some.conf in the backup/restore script because the backup script typically backups $install_dir anyway
sure for `/etc/*` i'm totally in line
[16:12:15]
<Aleks (he/him/il/lui)> to me the point of the data_dir should be exclusively the "filestore", as in "The app needs to be able to store user files / user assets which are binary files, possibly large, and it doesn't make sense to put them in an SQL database, so the app needs a directory for that" - typically the nextcloud files (which in the end i don't even know if they are in data_dir ? I hope so)
[16:12:29]
<Aleks (he/him/il/lui)> And then everything else goes in $install_dir
[16:13:03]
<Aleks (he/him/il/lui)> but i'm pretty sure someone could come up with a grey usecase where it's not straightforward to decide wether to put the stuff in data_dir vs install_dir
[16:17:56]
<m606> > <@Alekswag:matrix.org> to me the point of the data_dir should be exclusively the "filestore", as in "The app needs to be able to store user files / user assets which are binary files, possibly large, and it doesn't make sense to put them in an SQL database, so the app needs a directory for that" - typically the nextcloud files (which in the end i don't even know if they are in data_dir ? I hope so)
hmm ok I had more in mind something like user data and customizations in $data_dir and standard app files in $install_dir, but well that's not a big deal in the end and... I don't know yet exactly which files the app will put in the $data_dir they ask for in install instructions (also they don't have $install_dir...). I'll keep your view in mind for the experiments. thanks
[17:12:18]
<miro5001> > <@m606:matrix.org> @miro5001:matrix.org Would you remember why is the .bashrc line for here ? https://github.com/YunoHost-Apps/indico_ynh/blob/1a4be95bcfa0aac73252e648d3d5d692cc0c4bd9/scripts/install#L64
I didn't understand what you meant. This line will ensure python venv to be loaded when running yunohost app shell.
I don't remember the details, that was a while ago and I have struggled to get the app installed because in the indico documentation, the command to initialize the app was not unattended. After contacting the dev, he recommended to not run it at all and manually create the config file, the symlinks, etc
[17:17:46]
<m606> I might misunderstand something basic, but if I get line 63 (activate venv), I don't get why it that command is added in a .bashrc file ?
[17:18:08]
<m606> I might misunderstand something basic, but if I get line 63 (activate venv), I don't get why it that command is added in a .bashrc file (line 64)?
[17:18:41]
<m606> but maybe that was indico-specific and I shouldn't mind
[17:19:13]
<miro5001> > <@m606:matrix.org> hmm ok I had more in mind something like user data and customizations in $data_dir and standard app files in $install_dir, but well that's not a big deal in the end and... I don't know yet exactly which files the app will put in the $data_dir they ask for in install instructions (also they don't have $install_dir...). I'll keep your view in mind for the experiments. thanks
Data_dir for "data" including user data, customisations, and anything that will not need to be updated. Install_dir is for the app itself, with config file, venv.
But some apps have some hardcoded paths which makes it a case by case situation.
To make it easier for the user, adding an ADMIN.md with config file, customisations paths is a good idea
[17:20:24]
<m606> > <@m606:matrix.org> I might misunderstand something basic, but if I get line 63 (activate venv), I don't get why it that command is added in a .bashrc file (line 64)?
> This line will ensure python venv to be loaded when running yunohost app shell.
though I understand that now, just not why it would be required
[17:21:02]
<miro5001> > <@m606:matrix.org> I might misunderstand something basic, but if I get line 63 (activate venv), I don't get why it that comment is added in a .bashrc file ?
Oh, line 63 is for the install script itself. The following commands need to be run in the correct venv. Line 64 is for the app shell
[17:22:26]
<m606> > <@miro5001:matrix.org> Oh, line 63 is for the install script itself. The following commands need to be run in the correct venv. Line 64 is for the app shell
so that venv is activated while the app runs ?
[17:22:40]
<m606> not just during YNH scripts ?
[17:22:50]
<miro5001> > <@m606:matrix.org> though I understand that now, just not why it would be required
The app has some commands "indico db..." "indico user..."
These require the venv to be loaded
[17:27:03]
<m606> that are run by the app itself (i.e. when indico is run via the systemd service) and not only in the [YNH scripts](https://github.com/search?q=repo%3AYunoHost-Apps%2Findico_ynh+indico+db&type=code), right ?
[17:27:23]
<m606> that are trigerred by the app itself (i.e. after indico is initially run via the systemd service) and not only in the [YNH scripts](https://github.com/search?q=repo%3AYunoHost-Apps%2Findico_ynh+indico+db&type=code), right ?
[17:34:05]
<Nadine> How can I extract the version of a source from manifest? I know there is `$(ynh_app_upstream_version)`. But this only gives the package upstream version. In my package I have `resources.sources.main` and `resources.sources.frontend` and I need to get the version for the frontend source. Any hints?
[17:44:19]
<Aleks (he/him/il/lui)> eeeh that kind of depends how the version is encoded, i mean, you could extract the version number from the URL I suppose ? But that depends if that url contains the version number in the first place
[17:45:05]
<Aleks (he/him/il/lui)> or maybe downloading/extracting the asset and finding a file in there that contains the version number somehow
[17:57:26]
<miro5001> > <@m606:matrix.org> that are run by the app itself (i.e. when run via the systemd service) and not only in the [YNH scripts](https://github.com/search?q=repo%3AYunoHost-Apps%2Findico_ynh+indico+db&type=code), right ?
No I mean after installing it, it's possible to run some commands in the app shell.
Indico is written in flask. It requires two services. One for uwsgi and another for celery. The first one is for the web server and the second one is for scheduled tasks. That's all I know about them, till I get time to learn more.
[17:58:43]
<miro5001> And FluffyChat stopped sending notifications
[18:32:09]
<m606> > <@miro5001:matrix.org> No I mean after installing it, it's possible to run some commands in the app shell.
> Indico is written in flask. It requires two services. One for uwsgi and another for celery. The first one is for the web server and the second one is for scheduled tasks. That's all I know about them, till I get time to learn more.
i have a similar situation regarding services. I think I don't see very well what is "app shell"
[18:41:43]
<Nadine> Yes, the URL contains the version number at the end. I could use regex for extraction. And I could get the URL in install script with $(ynh_read_manifest -k "resources.sources.frontend.url"), right?
[19:03:27]
<miro5001> > <@m606:matrix.org> i have a similar situation regarding services. I think I don't see very well what is "app shell"
`yunohost app shell nextcloud` opens a shell prompt with the correct php version, home location set to /var/www/$app, environment variables, user set to $app, etc
So no need to have very long commands to run as root
[19:35:36]
<Aleks (he/him/il/lui)> yup 👍️
[20:16:07]
<m606> > <@miro5001:matrix.org> `yunohost app shell nextcloud` opens a shell prompt with the correct php version, home location set to /var/www/$app, environment variables, user set to $app, etc
> So no need to have very long commands to run as root
>
ah ok I have been going the root-long-command way so far! Now I see the purpose of that line - for YNH admins' convenience, not for the app itself
[22:21:43]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 8 pending update PRs
- 14 new apps PRs
- 14 failed apps updates: appflowy, khatru-pyramid, kiwix, languagetool, lemmy, localai, misskey, ofbiz, opencloud, phpldapadmin, phpmyadmin, pixelfedglitch, snweb, stremio
See the full log here: https://paste.yunohost.org/raw/loxedumevi