UPDATE: the original proposal was about excluding module_utils and doc_fragments content but during the discussion i realized that the true thing that confused me was displaying empty pages on the Documentation, so I agree with the folks the the Content tab should display everything but the Documentation tab should not display any undocumented entities.
plugins/module_utils contains Python code used by the modules/plugins
plugins/doc_fragments contains documentation shared by several or all plugins/modules like common arguments, notes, requirements, etc. so they are automatically included and present in corresponding modules/plugins doc pages there
As i think it brings no value to Galaxy NG users but rather confusion, i suggest excluding them and their content from the UI.
-1. It’s part of the content of the collection and can be reused by other collections (e.g. someone might be trying to figure out which version of amazon.aws added a doc fragment that they’re extending in a custom AWS plugin); it’s also possible for a collection to exist solely for the purpose of providing shared module_utilsand have no modules of its own.
I’m with @flowerysong on this one. If anything, I would prefer the UI to organize the “Documentation” page by the same content types as the “Contents” page. That would make it less confusing, even if there is no documentation being rendered.
I’m a bit torn here, but I tend to agree that they should be shown. This was a much more annoying problem with the old Galaxy since there everything that wasn’t a module was summed up under “plugin”, see for example the “Content” section for Ansible Galaxy - the module utils and docs fragments there are pretty much drown the other plugins by sheer mass. Fortunately this is no longer a problem with galaxy_ng, since there you can filter by plugin type directly (Ansible Galaxy).
If anything I would change the order so that module utils and doc fragments show up at the end of the filter list, since they tend to be least relevant for users. (Most users are not plugin/module developers.)
I fully agree here; the current separation into “Modules” and “Plugins” (and “Roles” and “Playbooks” I guess, if the collections have such) is very coarse, and for community.general it’s pretty useless since it’s a very long list of every kind of plugin: filter, test, cache plugin, inventory plugin, lookup, module utils, docs fragment, …
I would also not show undocumentable plugins here (like module utils and docs fragments and plugin utils) from the Documentation tab completely.
Ah, now i see, i ended up in the Documentation tab after clicking something undocumented in the Content tab. That’s how i got confused…
I agree displaying everything in the Content tab makes sense but in the Documentation tab only documented entities.
I’ll update the description. Thanks!
