Repository Organization

[dlamkins]

This repository should be organized in a consistent way to allow for details to be pulled automatically from within Blish HUD.

A simple proposal would be to organize it as the winget-pkgs repository organizes theirs.

[dlamkins]

And for that proposal:

bhud-pkgs
├─── tools
└─── manifests
    └─── group 1
    │   ├─── module-namespace or name 1
    │   │   └─── 1.2.3.json
    │   │   └─── 1.3.0.json
    │   │   └─── 1.3.4.json
    │   ├─── module-namespace or name 2
    │   │   └─── ...
    │   └─── module-namespace or name 3
    │       └─── ...
    ├─── group 2
    │   └─── ...
    └─── group 3
        └─── ...

• tools would contain likely a single script which can be used to generate the manifest from an existing module bhm.
• manifests would be the root of where module manifests or kept.
  • The name manifests used here is what is used in winget-pkgs, but I feel something like modules or something else could potentially be more descriptive.
• Groups folders (within the manifest folder) would be a grouping of modules by an "org" or individual publisher.
  • Org example: The existing Community Module Pack could be kept under a single "group" folder called bh-community.
  • Individual example: Tybalt's modules such as the screenshot manager could be held under a single "group" folder called tybalt or perhaps nekres (depending on his preference).
  • It could be appropriate for the group name to match a portion of the module's namespace. If this was done, the "module-namespace" folder within it would be better suited to just using the modules name instead of the namespace to avoid being redundant.
• Module folders (within Group folders) would be a folder containing the manifests for a single module.
  • The directory name should match either the namespace or the module's name listed in the manifest depending on the naming convention decided for the group folders.
• Manifests (within the Module folders) would be a manifest representing the release of a module. The name of the manifest should reflect the version of the module (for example 1.3.0.json) to allow for multiple releases of a single module. This would allow Blish HUD to identify the module version best suited for the currently running version of Blish HUD (especially helpful in the case of older versions of the overlay where the latest module release may not be compatible).

Group name dependency on a module's namespace would likely require a modification to the module manifest schema to enforce namespaces be at least 1 layer deep. As of right now, namespaces only act as a unique identifier and don't necessarily require a particular format. More on module manifest namespaces.

[dlamkins]

We have moved forward with this implementation.