Replace programming language with categories

[secustor]

Describe the proposed change(s).

The other category of the manager docs has become quite big.

I propose following refactor to improve visibility for new users:

manager	old category	new category
ansible	docker	ansible
ansible-galaxy		ansible
argocd		kubernetes (cd?)
azure-pipelines		ci
batect		batect
batect-wrapper		batect
bazel
bitbucket-pipelines		ci
buildkite		ci
bundler	ruby	ruby
cake	dotnet	dotnet
cargo	rust	rust
cdnurl		cd?
circleci		ci
cocoapods		swift
composer	php	php
deps-edn		jvm
docker-compose	docker	docker
dockerfile	docker	docker
droneci	docker	ci
flux		kubernetes (cd?)
git-submodules
github-actions		ci
gitlabci	docker	ci
gitlabci-include		ci
gomod	golang	golang
gradle	java	jvm
gradle-wrapper		jvm
helm-requirements		helm
helm-values		helm
helmfile		cd?
helmsman		cd?
helmv3		helm
homebrew
html		cd?
jenkins		ci
jsonnet-bundler		kubernetes
kubernetes	docker	kubernetes
kustomize		kubernetes
maven	java	jvm
meteor	js	js
mix	elixir	elixir
nodenv	node	node
npm	js	js
nuget	dotnet	dotnet
nvm	node	node
pip-compile	python	python
pip_requirements	python	python
pip_setup	python	python
pipenv	python	python
poetry	python	python
pre-commit
pub		dart
pyenv	python	python
poetry	python	python
regex
ruby-version	ruby	ruby
sbt		jvm
setup-cfg	python	python
swift		swift
terraform		terraform
terraform-version		terraform
terragrunt		terraform
terragrunt-version		terraform
travis		ci

[viceice]

I think we should fully remove the languages and add a new tags option which can have multiple values.

This should also be matchable via package rules.

[rarkins]

Maybe the term "category". I would like to remove language as a semantic concept including from package rules

[rarkins]

In most cases it would be better replaced by datasource matching in package rules

[HonkingGoose]

Use list styling for long lists

We have too many managers under the other category, and it's hard to read because its not styled like a list.

Until we rewrite the code to the new structure, could we at least make long items like this go in a list? Like this:

Supported Managers

...snip...

Other:

• ansible-galaxy
• argocd
• azure-pipelines
• And so on

I'd want us to change the supported datasources section as well, so it looks like this:

Supported Datasources

Supported values for datasource are:

• adoptium-java
• artifactory
• aws-machine-image
• And so on

---

Use tags feature in Material for MkDocs???

This might be relevant/helpful. If you sponsor Material for MkDocs, you get access to the tags feature. Quote from feature page:

Material for MkDocs adds first-class support for categorizing pages with tags, which adds the possibility to group related pages and make them discoverable via search and a dedicated tags index. If your documentation is large, tags can help to discover relevant information faster.

I have not tried this feature, so I don't know if it would make things better for us.
The Material for MkDocs, setting up tags documentation has some screenshots that you can look at.

[secustor]

I think to have option to give managers multiple categories is definitely useful. e.g. helmsman and helmsfile could have helm as well as cd .

In most cases it would be better replaced by datasource matching in package rules

I think there are enough use cases like ansible and ansible-galaxy where it not visible to the users which data sources they can expect.

[rarkins]

I have an issue open to discuss making managers declare their supported datasources so that we can convert that to docs

[HonkingGoose]

I have an issue open to discuss making managers declare their supported datasources so that we can convert that to docs

@rarkins It sounds like you're thinking of this issue?

• Enforce manager -> datasource links for better documentation #5651

[secustor]

To summarize, the requirements are so far:

• matchLanguage should for package rules should be dropped
• the ProgrammingLanguage should be rename into Category
• Category should be able to hold multiple values

The topic of long lists and MkDocs tags earns an own issue IMO.

[HonkingGoose]

@rarkins what's the best order to tackle these items?

• Enforce manager -> datasource links for better documentation.
• Refactor code as described in the comment above.
• Use list styling for long lists.
• Use tags with MkDocs, once we're sponsors.

[rarkins]

I think more generally:

1. We need config warnings to be more visible

Dashboard is mostly sufficient, but I think sometimes content is "lost". For config warnings, we should make sure the message is sufficient.

I think we could also add a message to each PR which says something like ":warning: this repository has warnings. Please check the logs of Dependency Dashboard for details". This should draw more attention.

2. We should deprecate languages

This should last for enough time so that people have the chance to see the warnings and change their config. We may want to give a guide to migrating from them in the docs.

3. We remove languages support in a major release

Major bumps don't help repo users - only admins - so that's why we need (2) above to try to alert people first.

Back to the original point, our language-based grouping of managers in docs is not great. I think we could change the docs grouping - whether manually or automatically using categories - independently of the above languages deprecation.

[secustor]

1. We need config warnings to be more visible
2. We should deprecate languages
3. We remove languages support in a major release

1. Already implemented: refactor: config warning/error fields #9349
2. TODO
3. TODO

Implementation of categories:

• feat!: categories #16534

[renovate-release]

🎉 This issue has been resolved in version 36.0.0 🎉

The release is available on:

• GitHub release
• 36.0.0

Your semantic-release bot 📦🚀