[04:18:41]
<Yunohost Git/Infra notifications> Failed to run the source auto-update for : cinny. Please run manually the `autoupdate_app_sources.py` script on these apps to debug what is happening! Debug log : http://paste.yunohost.org/raw/ediqixoqol
[07:02:23]
<ChriChri> > <@Alekswag:matrix.org> alternatively you can "convert" an existing install to a dev environment, cf the "remote path" of the ynh-dev README (which is mainly worded around "VPS" but can be applied to any regular yunohost install)
Hm, I didn't understand the whole dev process, yet, but I'll try in my words what I learned for my situation:
* since I have a kine of VPS (my dedicated development system - even though it is not virtualized) I don't need VXD, because there is no conflict with the host system running services
* just go ahead on the RockPro64 - install yunohost like before, clone git, call the git-related commands to do stuff
* get (another) IP for your dev plaltform if you want to actually test stuff that is needing internet (I guess two yunohost cannot share one IP)
What I wonder is _whether it is possible to just build packages on the dev system and then test them on my productive yunohost_. This would be to avoid the need for a second IP and to have stuff I tested already 'offline' being tested on a system actually running.
[09:16:03]
<Aleks (he/him/il/lui)> by "build packages", do you really mean "build packages" ? 😬
[09:17:44]
<Aleks (he/him/il/lui)> everything also sort of depends on what kind of stuff you want to develop/test though, if it's python and the change is somewhat minimal, you can be a bit yolodirty and just edit the python files in a production environment and test if the command / API are reacting as expected, but for stuff a bit more complex that this you usually sort of need a proper git clone + symlink (what ynh-dev does)
[09:18:00]
<Aleks (he/him/il/lui)> "actually building .deb packages" is not something really necessary usually
[10:19:21]
<orhtej2> I assume CHRICHRI wants to replicate 'install on Debian' steps with artifacts from a branch with his changes.
Or at least a way to apply modified files to an existing ynh installation for iterative development
[10:44:30]
<ChriChri> Uhm, I meant a development cycle like
* change stuff in some repo that could produce MRs or in a personal branch
* build packages
* install on test system (to emulate the end user experience)
* adopt changes until good using above steps
* generate MRs from what really works or checkin to repo
The _change stuff_ step clearly takes place before trying to integrate into packages on a test system. But sometimes the point is reached those changes need to be converted into MRs - and a good way to do that I'm looking for.
So, yes, _a way to apply modified files to an existing ynh installation for iterative development_ is something I'm looking for.
[13:08:50]
<Yunohost Git/Infra notifications> [yunohost] @Axolotle pushed 2 commits to pydantic ([913451560478...3faa57426740](https://github.com/YunoHost/yunohost/compare/913451560478...3faa57426740))
[13:08:55]
<Yunohost Git/Infra notifications> [yunohost/pydantic] configpanel: forbid extra props on BaseOption + accordingly fix tests - axolotle
[13:08:56]
<Yunohost Git/Infra notifications> [yunohost/pydantic] configpanel: add proper schema definition - axolotle
[13:16:24]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#1049082770](https://gitlab.com/yunohost/yunohost/-/pipelines/1049082770) failed on branch pydantic
[13:21:17]
<Yunohost Git/Infra notifications> [yunohost] @Axolotle edited [pull request #1677](https://github.com/YunoHost/yunohost/pull/1677): ConfigPanel: switch to pydantic 3/3
[13:31:53]
<axolotle> Here's a first app's config panel JSON schema https://github.com/YunoHost/yunohost/pull/1677 (in the PR message there's a disclosure with the schema if someone wants to test it)
It works well with JSON but with TOML with ([taplo](https://taplo.tamasfe.dev/)) error messages are not very helpfull (but validation looks ok) ...
It probably has problems with the SectionModel `"oneOf"` rule of `"additionnalProperties"`, it doesn't pick the option based on its `type = "string|boolean|etc"`
[13:37:30]
<axolotle> > <@chrichri:librem.one> Uhm, I meant a development cycle like
> * change stuff in some repo that could produce MRs or in a personal branch
> * build packages
> * install on test system (to emulate the end user experience)
> * adopt changes until good using above steps
> * generate MRs from what really works or checkin to repo
>
> The _change stuff_ step clearly takes place before trying to integrate into packages on a test system. But sometimes the point is reached those changes need to be converted into MRs - and a good way to do that I'm looking for.
>
> So, yes, _a way to apply modified files to an existing ynh installation for iterative development_ is something I'm looking for.
You could probably follow https://github.com/YunoHost/ynh-dev#remote-development-environment. Like that you can have a "test system" on which you work directly, modifications to source code will by directly available and you will have your git workflow there too