Skip to content

Change naming convention for Flatpak manifest files #406

Open
@janopae

Description

@janopae

Currently, the docs propose to name the manifest file {appliction-id}.yaml or {appliction-id}.json. This makes sense when a repository (or directory) contains multiple manifests for different applications.

However, the docs also propose to use this naming convention for their example, where the Flatpak manifest lives directly with the application itself in the same directory.

In such a case, this kind of file name is not very helpful: The information to which application the manifest belongs is already provided by the location of the file (the VCS repository) and by its contents (which also contains the application id). At least the file name provides the information that it is in yaml/json format, but it says nothing about its structure or meaning in the context of the repository.

This has the following disadvantages:

  • developers who don't know about Flatpak have a hard time finding out what the file is for. The best they could do would be asking ChatGPT or a human.
  • IDEs have a hard time providing autocompletion
  • finding Flatpak manifests in an unknown repo can be hard (both manually and for scripts)

I propose the following convention instead:

If the target of the Flatpak manifest is unambigous given its location (e. g. the repository it lives in), simply call it flatpak-manifest.yaml/flatpak-manifest.json. If there are multiple flatpak manifest files in the location, give it a prefix that tells it apart:

  • A manifest for the nightly build of the app in the containing repo might be called nightly.flatpak-manifest.yaml
  • A manifest for the dependencies that gets imported by other manifests might be called dependencies.flatpak-manifest.yaml
  • A manifest living in a repo along with other manifests for different applications might be prefixed with the application id (org.example.app.flatpak-manifest.yaml)

The advantages of this naming convention:

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions