Replace package-ecosystem with specifying both language and package-manager in dependabot.yml

[jeffwidman]

Today dependabot.yml takes package-ecosystem as an input argument, which conflates the idea of language and package manager.

This issue is a placeholder for discussions about replacing package-ecosystem with explicitly specifying both package-manager and language args.

Typically we think of package manager as a subset of a language, as in a language may have multiple package managers. But there are times when a single package manager may apply to multiple languages. An obvious example is docker images which are specified in:

• dockerfiles: currently supported by
• Kubernetes files: currently supported by
• Docker-compose: Support for Docker compose files #390
• GitHub actions: Bump docker image references in GitHub Actions workflow #5541, [Docker] Update docker images declared in action.yaml files #6892, and Update container image references in GitHub Action workflows #5819
• Azure pipelines: Support for bumping docker containers inside azure-pipelines.yml? #2194
• Maven files: Update Docker image tags in Maven files (pom.xml) #6234

So it's really an N:N relationship rather than a 1:N relationship.

More observations:

1. package-ecosystem is simply confusing... the term ecosystem is ambiguous... is that a language, a package manager, or the combo of the two? Versus "language" and "package-manager" are well understood concepts across programmers.
2. Even though humans tend to think of package managers as a subset of language, operates from the perspective of the package manager. So we could probably still get away with a 1:N relationship, but with the package manager as the top-level key, and languages as a subset.
3. There's no way for a user to say "I do want docker images bumped in these types of files but not in these other types of files". This will become particularly relevant for grouped updates. For example, if someone wants the docker images bumped in their dockerfiles and github actions, and they want it done via a grouped PR, but they don't want the kubernetes deploy files included in that PR...
4. The docker image case is complicated, because we'll probably need native helpers--eg, parsing Dockerfiles would be more powerful if we used the native go-based Docker library. But we couldn't use that on Maven files, in fact we'd probably want a native Maven helper for parsing out the docker image tags. So we end up running separate jobs for "docker images within Maven" vs "docker images within dockerfiles"... plenty more examples of that.
5. Looking at 4️⃣ , the truth is our "jobs" that we run will probably be the unique combo of language + package-manager... so we may not be able to always group updates within a given package manager since it may span multiple languages, and require multiple native helpers. Since it's the combo of the two, whether they're treated in the config file as package manager as a subset of language, language as a subset of package manager, or both top-level keys doesn't really matter... we'd regardless be generating the matrix permutations to determine which jobs to run.
6. Docker + GitHub actions turns out to also be complex... see the variety of ways docker images get specified, we could probably get away with assuming if users want docker images bumped in their docker actions, they want all images bumped and implement all three requests ([Docker] Update docker images declared in action.yaml files #6892, Bump docker image references in GitHub Actions workflow #5541, Update container image references in GitHub Action workflows #5819) under the single language of GitHub Actions, but it'd be worth double-checking that.

A related problem to all this is that today we "guess" which package manager to use. This causes some related problems where again, requiring the user to explicitly configure the package-manager would help:

• Require users to explicitly specify which python package manager they want to use #7188
• Simplify hybrid manifest/lockfile cases in NPM ecosystem #7184

Two complicating factors to all this:

• Security update PR's happen on repositories that may not have a dependabot.yml file, so how do we support those if we're not able to guess?
• Please restore ability to work without a configuration file #3603:
  • this doesn't have a lot of upvotes, but from a perspective of increasing user adoption it's easier for users to click an "enable Dependabot" button rather than write a config file... there's a larger cognitive barrier to a file.
  • Also there's an ownership issue here - sometimes security teams within an org want to enable Dependabot across the org, but don't want to commit config files to repos, because politically the repos are owned by the developers.

[jeffwidman]

I should add that while doing this would get us to a much better place, the migration process may be a little painful because it'd be a large breaking change... so we'd want to probably do it in conjunction with a bunch of other API changes on the config file and release a v3 schema.

At that point we could auto-open PR's against repos to move them to the newer config, or possibly map old config to reasonable defaults... However, I suspect the 🥕 of all the new features would entice a lot of our active users to move to the new config file API version as long as we clearly alert them of its existence.

Anyway, all that to say, this is something we'll need to put a good bit of thought into before moving forward on.