[15:37:00]
<Yunohost Git/Infra notifications> [issues] eauchat opened [issue #2604](https://github.com/YunoHost/issues/issues/2604): Create a setting to add a prefix to the subject of all emails automatically sent by yunohost
[15:37:02]
<Yunohost Git/Infra notifications> [yunohost-admin] tituspijean created new branch donation_link
[15:37:03]
<Yunohost Git/Infra notifications> [yunohost-admin] tituspijean pushed 1 commit to donation_link: Point donation link to the website ([71133b71](https://github.com/YunoHost/yunohost-admin/commit/71133b71abf090c53b57a26b1c3c6524959e0f72))
[15:37:04]
<Yunohost Git/Infra notifications> [yunohost-admin] tituspijean opened [pull request #639](https://github.com/YunoHost/yunohost-admin/pull/639): Point donation link to the website
[15:37:06]
<Yunohost Git/Infra notifications> [issues] tituspijean edited [issue #2603](https://github.com/YunoHost/issues/issues/2603): End of 2025 donation campaign
[16:05:51]
<Yunohost Git/Infra notifications> [Apps tools error] [List builder] Error while updating fusion: No cache yet for fusion
[17:46:21]
<Yunohost Git/Infra notifications> [yunohost] fflorent [commented](https://github.com/YunoHost/yunohost/pull/2122#discussion_r2160415723) on pull request #2122 Implement RedisAppResource: A big issue I have just discovered when working on a package: not only we have to look for a free database on installati...
[17:47:01]
<Yunohost Git/Infra notifications> [yunohost] fflorent edited [pull request #2122](https://github.com/YunoHost/yunohost/pull/2122): Implement RedisAppResource
[17:47:25]
<Yunohost Git/Infra notifications> [yunohost] fflorent edited [pull request #2124](https://github.com/YunoHost/yunohost/pull/2124): Redis app resource (implementation alternative)
[17:47:59]
<Yunohost Git/Infra notifications> [yunohost] fflorent [commented](https://github.com/YunoHost/yunohost/pull/2124#discussion_r2160415961) on pull request #2124 Redis app resource (implementation alternative): [Same questions as here](https://github.com/YunoHost/yunohost/pull/2122/files#r2160415723)
[17:48:44]
<florent[m]> I would hightly appreciate help for these questions for the Redis AppResource 🙏: https://github.com/YunoHost/yunohost/pull/2122#discussion_r2160415723
[17:53:04]
*Aleks (he/him/il/lui) looks at his mental todolist in horror
[17:54:49]
<Aleks (he/him/il/lui)> >A big issue I have just discovered when working on a package: not only we have to look for a free database on installation / upgrade, but also on restoration.
yeah in fact there are other stuff for which we should be doing this, such as ports which may be used by other apps on the target system (eg when restoring on another machine)
[17:55:23]
<Aleks (he/him/il/lui)> but i suppose there's a higher changes for redis because of the "small integer" it's using
[17:55:45]
<Aleks (he/him/il/lui)> (btw i don't know much thing about redis but couldn't we choose a random index between 0 and some large integer ?)
[18:34:53]
<florent[m]> I don't either. Yeah, it may solve the issue, but according to this article (that is just a blog post, not an great authority answer), it may lead to performance issue:
https://medium.com/@leonardogilrodriguez/redis-customization-increasing-the-number-of-databases-for-local-environments-e745aa874d1f
(and I guess that if it were not, the default number would be way higher)
[18:35:43]
<Aleks (he/him/il/lui)> hmokay 🤔
[18:36:35]
<florent[m]> (I am no authority on this, not that high confidence)
[18:38:33]
<florent[m]> That being said, the point about the port is interesting. We may solve the two issues by one shot if we provide a solution.
Shall I write an issue to discuss proposals?
[18:39:30]
<florent[m]> (and may we consider this issue as not blocking my above PRs about RedisAppResource? Or would it be worrying?)
[18:41:53]
<Aleks (he/him/il/lui)> i'd say it's not blocking yeah because in the current status quo we probably have many apps not re-checking for the redis port etc ... i'm ranting/rambling but packaging v3 will probably help with this, imho restore should ideally regenerate everything it can from scratch (except for example cache / node_modules which is debatable because it's not free, and manually modified conf)
[18:43:05]
<Aleks (he/him/il/lui)> well it's bit more complex than that tho ... if you manually modified the nginx conf, and the restore picks a different port, it won't be updated in the nginx conf meh
[18:44:14]
<Aleks (he/him/il/lui)> but i digress
[18:52:25]
<florent[m]> Yeah, I was thinking about it too. Maybe there is room for a workflow like:
- if no port / redis database have been changed, just restore the files as they are stored in the backup;
- if they were changed, we can reapply the config files (and helpers like `ynh_config_add` / `ynh_config_add_nginx` / `ynh_config_add_systemd` / ... called during installation / upgrade can track on which file they are used). If the user brought changes, then this would be the same behavior as during an upgrade;
[18:55:20]
<florent[m]> That being said, I should maybe take a look at packaging v3 before suggesting. Do you already have plan written somewhere for that? (or is it too early?)
[18:56:01]
<Aleks (he/him/il/lui)> it's already work in progress :
- cf the "main item" in https://github.com/YunoHost/issues/issues/2136
- and todolist in https://github.com/YunoHost/yunohost/pull/2070
[18:57:39]
<Aleks (he/him/il/lui)> basically there won't be any "install" / "remove" / "upgrade" / "backup" / "restore" script, the remove/backup/restore part should be entirely automated by the core (with some possible bash hooks to cover specific cases but in the nominal case it shouldnt be necessary). "install" and "upgrade" should become a simple `scripts.sh` with functions like build(), initialize(), migrate(), run as non-root, with some specific functions when needing to run stuff as root
[18:58:00]
<Aleks (he/him/il/lui)> and configurations are to be handled declaratively, similar to the resource mechanism
[18:58:48]
<florent[m]> (sounds very interesting!)
[18:59:47]
<Aleks (he/him/il/lui)> and some improvements to the resource mechanism, such as turning the "database" resource into a "multi" resource
or having "conditional" resources with an if clause
[19:00:09]
<Aleks (he/him/il/lui)> for example my_webapp only needs a mysql db if you enable the option
[19:00:59]
<Aleks (he/him/il/lui)> and i have a few ideas to further improve security
[19:02:25]
<Aleks (he/him/il/lui)> hoping to have a beta somewhere by the end of the year if not before i "just" need to find ... time to <del>think deeply while staring at my screen for hours</del>code
[19:08:47]
<florent[m]> Can I modestly help on this or will it be a burden to have to worry about other's work? (I would totally understand the second answer, I see that there exist plenty of work outside of V3)
[19:09:02]
<Aleks (he/him/il/lui)> hmmmm but back to the redis resource i'm trying to think how to move forward ... mostly because i was wondering if in the mid-term we want to have "redis" just being a type of the "database" resource ... on the other i'm realizing that redis has significant differences compared to the SQL db so maybe it make sense to keep them as separated stuff, and that would solve the thing about "do we wait or not for packaging v3"
[19:09:03]
<Aleks (he/him/il/lui)> then looking at the use cases in apps, i don't see any apps using several redis DB or using a different name than "redis_db" for the setting so i'm wondering if the complexity in `__init__` etc is needed ?
[19:09:18]
<Aleks (he/him/il/lui)> (sorry lost the internets for a few sec)
[19:09:36]
<florent[m]> (no problem)
[19:10:07]
<Aleks (he/him/il/lui)> hmmmmmm
[19:10:55]
<florent[m]> I am packaging 2 of them (not official yet, and *maybe* it is not necessary, but I would say probably it is)
[19:15:13]
<Aleks (he/him/il/lui)> hmmm trying to think, it's a bit tricky because it's some epic refactoring buuuuuuuut hmmm at the end of the todo i noted some R&D thing about
>Create the 'v3' helpers ? See how much we can get rid of ... explore having a mechanism a mechanism with "python helpers" for helpers we want to keep callable from bash but that would mean duplicated logic between bash and python
basically the idea is that on the mid-term / long-term it would be nice to reduce the amount of bash helpers, especially for stuff that are supposed to be handled declaratively such as the apt resource (which actually still has some helper called by the core), mysql / postgresql db creation/deletion (same), etc ... So naively we want to convert those to "pure" Python (ofc with system calls sometimes)
*but* unfortunately we can still expect some cases where people will need to call stuff manually from their script, so we'd need a way to, for example, have helpers that call the apt resource code somehow from bash ...
[19:16:50]
<Aleks (he/him/il/lui)> *and* one thing to get rid of too ideally is the damn getopts stuff (though we could discuss it's not really a necessity) and i was wondering if we couldnt in fact have some sort of new python CLI such as `ynh_helpers` where the argparsing would happen in the python code (so no ugly bash getopts etc) and that would call the appropriate python function
[19:18:20]
<Aleks (he/him/il/lui)> but it remains to be seen how that would be designed exactly : the resource system (and new configuration system) is designed with a bunch of context so what are the use cases, how would that be called from a new `ynh_helpers` python program that would ideally be lightweight and not be "the full yunohost command" (which could also be an option)
[19:19:04]
<Aleks (he/him/il/lui)> not sure if that's clear but basically that would move the helper system to be just a mapping of some bash function to python functions (with some new python program being the bridge)
[19:21:27]
<Aleks (he/him/il/lui)> so anyway, bottom line is, if that's your jam, that would be a cool topic to work on somewhat independently of the rest ;P
[19:21:48]
<Aleks (he/him/il/lui)> though sooner or later i'm gonna have a look at "what helpers do we trash" and "how to not duplicate the logic between bash and python for the helpers we keep"
[19:25:54]
<florent[m]> I can take a look, to be honest, I think I would need an easy task of this work (or not-that-hard) to convince myself whether that's the kind of stuff I could do, or just admit that's not for me, as I don't write much Python (I am a JS developer).
[19:26:30]
<Aleks (he/him/il/lui)> hmmmkay, but then having "dynamic keys" (i.e. your property dicts end up being something like `{"foo": {} , "bar": {"previous_names": ['whatev']}}` with foo / bar being chosen by the packager but uuuuhh not very practical for the refactoring of the resource i'm doing right now 😅
Couldn't we have just something like
```
[resource.redis]
names = ["redis_db", "celery_db"]
```
(but then we lose the ability to have options for each db merp)
[19:27:04]
<Aleks (he/him/il/lui)> (sorry i'm brainstorming out loud 😬)
[19:27:18]
<florent[m]> No problem, I do that often too
[19:27:20]
<Aleks (he/him/il/lui)> ah nvm it's not not-practical it's just a "multi" resource like ports etc
[19:28:42]
<Aleks (he/him/il/lui)> or maybe something like:
```toml
[resource.redis]
main.setting_name = "redis_db"
celery.setting_name = "celery_redis_db"
celery.previous_names = ["celery_db"]
```
[19:29:59]
<florent[m]> That being said, I know the developers who develop the apps I package. Maybe I should first ask whether that's really necessary (if there exist risks of key collisions), and if not (and if there don't exist other packages requiring several redis dbs), maybe I should simplify as you requested earlier.
[19:32:13]
<Aleks (he/him/il/lui)> i guess it makes sense to have several redis DB in some context, eg maybe one to manage session keys and the other one to manage a job queue list, i was just wondering if this is over-designing etc
[19:33:34]
<florent[m]> Hmm, sounds like the two apps (docs\_ynh and visio\_ynh) I package / co-package are not the only ones in this case ([bookwyrm](https://github.com/YunoHost-Apps/bookwyrm_ynh) and [indico\_ynh](https://github.com/YunoHost-Apps/indico_ynh))
[19:34:12]
<Aleks (he/him/il/lui)> yeah sorry maybe i got carried away haha but on the other hand it's a good context to learn python because that would involve creating a python program "from scratch" while using argument parser and yunohost as python lib ... maybe we could try to reduce the scope to something more concrete like "What if a packager wants to add an apt resource to its existing apt resource from its bash script but without relying on the current helpers that will disappear, and instead calling the apt resource code" etcblblblbl
[19:34:25]
<Aleks (he/him/il/lui)> we could schedule a binome coding session idk
[19:42:49]
<florent[m]> About the case you introduce, I think I would first need a concrete example of package where this is the case you mention.
I am not sure about what the use case you mention (with my current understanding, it should be covered by `packages_from_raw_bash`, there's probably something I don't fully understand).
[19:44:04]
<Yunohost Git/Infra notifications> [yunohost] alexAubin [commented](https://github.com/YunoHost/yunohost/pull/2122#discussion_r2160452474) on pull request #2122 Implement RedisAppResource: So if I understand correctly, that trick with provisionned_redis_db_names is to be able to keep track of what redis DB...
[19:44:51]
<Aleks (he/him/il/lui)> weeeeell for example there is nextcloud 😬 for which during the upgrade we need to have all the appropriate php packages for each major version (because we need to go through each major version)
[19:45:18]
<Aleks (he/him/il/lui)> https://github.com/YunoHost-Apps/nextcloud_ynh/blob/master/scripts/upgrade#L83
[19:45:36]
<Aleks (he/him/il/lui)> in that case that's more like "replace all the dependencies of the ynh-deps-nextcloud"
[19:46:00]
<Aleks (he/him/il/lui)> jellyfin has some weird shit too
[19:46:19]
<Aleks (he/him/il/lui)> (but yeah you're right it needs to be driven by real-life usecases)
[19:46:46]
<Aleks (he/him/il/lui)> https://github.com/YunoHost-Apps/jellyfin_ynh/blob/master/scripts/_common.sh#L76
[19:47:00]
<Aleks (he/him/il/lui)> https://aria.im/_bifrost/v1/media/download/ATthM1vr0JIJxdAXXa0nhU2Td9gO3umv-LgUfnbBbv7bO3KxqNdUk8WYUWtVJDisFFe38NIcCNE2ahbEcyMY8g9CeXnlRjLAAG1hdHJpeC5vcmcvcE5KYVh6U1VsRUd0Y3JUdFBrdFBXTmNw
[19:48:25]
<florent[m]> Hmm, actually that's interesting and I should take a look. I write a summary of this conversation and add it to my personnal todo (once I have finished my two packages + the RedisAppResource, I should take a look at it)
[19:54:10]
<florent[m]> Oh wow, you circumvent an issue with the current implementation of `ynh_redis_get_free_db` that returns the same value when called twice successively? 😵
[19:55:05]
<m606> yes that's the point of the "lock" (although it's not my idea - i copied it from another package in Yunohost-Apps)
[19:55:21]
<m606> or somewhere on internet, not sure anymore
[20:07:13]
<m606> the idea came from indico_ynh and @miro5001 (we had a talk on this between 2 and 7 April 2025 in #yunohost-apps:matrix.org if that can be of interest to you)
[20:40:03]
<Yunohost Git/Infra notifications> [yunohost] fflorent [commented](https://github.com/YunoHost/yunohost/pull/2122#discussion_r2160483499) on pull request #2122 Implement RedisAppResource: > So if I understand correctly, that trick with provisionned_redis_db_names is to be able to keep track of what redis DB...
[20:41:51]
<florent[m]> I have already covered this in my implementation for RedisAppResource, but for other reasons. But yeah, I need to also do that for my packages.
Thanks for the tip!