Show farmOS contrib module info in farm/settings/modules

Thinking about this a bit..

I think using composer.json would be easier, because they already include information like project URL, alongside description, etc. We could also consider adding some custom properties.

Notably, *.info.yml has a description as well! And it seems like we can toss custom properties in there. Also there's already a Drupal service provided for loading this module info, and we're already using it which makes it a bit more convenient: https://github.com/farmOS/farmOS/blob/1a7582b8abb719828d5a7f707780248974...

do we do the same thing with farmOS core modules? I think we should. But those don't have composer.json files...

Also submodules from a contrib module! These wouldn't have composer.json either. I think *.info.yml is our best bet.

For example, it would be great if we could easily see which asset, log, plan types the module adds... or which flags, etc. These could potentially be detected from the module's config/install directory.

Should we consider re-structuring the fieldsets to be the different high-level farmOS packages, instead of a core/contrib distinction? Each module could have (Core) or (Contrib) appended to its name in different colors to differentiate the two types. I'm attaching a screenshot of what these packages look like right now in the admin/modules page. I guess it largely depends on the user, but this type of navigation seems like it would be more effective than clicking through individual modules to see what they provide. For example, I like that "farmOS Maps" has it's own category. This is really intuitive! (maybe we drop the "farmOS" prefix and only have a subset of the current ones?)

I guess when it comes to flags, id tags, categories... higher level fieldsets would be excessive. But maybe a hybrid of more high-level categories, with "tags" for these different config entities they provide?

Of course it's possible for a module to provide multiple of these different entity types... but maybe this helps encourage separating such features into distinct modules? A module could always choose to be a part of a more general "farmOS Contrib" package as well and use the "tags" to show what all it provides. Could we allow contrib modules to create their own categories too?

So... what if we added new farm_module_link and farm_module_category properties to *.info.yml. These could be used instead of the current module package to show more info about core & contrib modules?

What if we just keep this super simple for now and just add the description text next to the module's name? Then it's up to the module maintainers to make sure their descriptions are decent?

Done! This is a pretty simple change. I made it so the core module descriptions are used as well, but we still use the special names we have given them. Attached is a screenshot of what this looks like.

Contrib will always be less granular than core too. We break things up into very specific modules by the type of thing they provide in core, but contrib will probably tend to put lots of different types of things in the same module - categorizing more on the subject matter than the granular data types. I don't think we need to discourage this.

Good points, I agree. Maybe it would be worth while having those "subjects" be high-level categories just under the farmOS Contrib fieldset. But easy to let that be TBD and add later once there are more contrib modules and a need to organize them.

Adding descriptions nearly doubles the length of the list. It seems that descriptions might not be needed for *all* of the core modules, but I think it is good to have for others.