Proposition to improve app packaging format

Contribute Room Apps packaging
1

@Apps @Dev
Hi,

I was updating a new app and saying why i redo and redo and redo the same things when I package the app. And each time, this situation arrived, I say me we should have a more complete manifest (or some filename convention) to have the same bash scripts (install, upgrade, remove, backup, restore, changeurl) for each apps. Those bash script could interpret manifest and configure the app by detecting automatically, which technology, which setup method…

So I have started a pad, to see if there is a possibility to create something like a draft of a new packaging_format…

https://pad.lqdn.fr/p/ynh_packaging_format_2

Waht is your point of view about this ?

2

Don’t hesitate to give example of some specific app wich couldn’t be manage like this and why.

3

That’s why there’s a example app. I hope you don’t build your apps from scratch !?

So… I don’t want to break any momentum, I read some really good ideas, but in a general way we still have the same conflict together. I like to keep the scripts easily readable and understable.
And I’m really not for too much abstraction. I’d like to keep the usage of helpers as a sufficient abstraction to keep to the packagers an easy way to do some complexe actions. But still keep this action (the helper in the script) to know what the script doing.

However, it’s only my point of view.

4

Hello,

I think there are many good Idea in this document. I also think that many things could be implemented in the core instead of in the script. For example the helper ynh_normalize_url_path.
I also think that all settings who is got by ynh_app_setting_get could be passed in the environment.

I think, there are also some others things but I don’t remember.

5

I share the point of view of Josue: there are many good ideas in this document. Some are easy to add to our mechanics, some are quite difficult to implement.

The list in itself is too long! I don’t have time to fully read it.
The document also focus on answer, without issue analysis, making it difficult to understand if the solution is the good answer for the issue.

let’s try to make it explicit and answer the beginning:

  1. Dependencies
    Dependencies could be listed in the manifest like that we will be able to setup dependencies automaticcaly
    ==> sounds good, why not.

  2. Build dependencies
    We could separate “build dependencies” from the dependencies to run the program
    ==> maybe, but this is a concept, not a solution.

  3. Conditionnal dependencies
    Some app need to setup some package only in some situation, we could imagine a function that could be overwrite to modify dynamically the dependecies list
    ==> why not, but this isn’t compatible with [1.] or will create too much complexity

  4. Non apt dependencies
    A common issue is the need to setup some pip/npm dependencies
    In some app there already be a dependencies file, in other there isn’t
    ==> Well, let’s add it to https://github.com/YunoHost-Apps/Experimental_helpers

  5. Sources
    We already have a source management with the app.src, but some app need more than just one app.src (for example to add some plugin or because it’s a mix of several sources) and we don’t know were it should be set up.
    By default it should be /var/www/$app , but specify it clearly could be usefull
    ==> sounds good, why not.