Inform about new releases via issues (eco system independent)

[Leon0402]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

There has been already the feature request to add support for a mode of dependabot, where it wouldn't automatically bump versions via PR, but rather open an issue and only inform about new releases (see #2242)

This feature request enhances this idea by suggesting to add this mode as a sort of package manager. The idea is that this mode would work for any eco system, even those, which are currently not supported by dependabot.

Support for the C++ Ecosystem is a good example for this (#2027). Because C++ offers many ways to integrate dependencies and is not really of a priorization for the team, it is very unlikely that it will be ever partially or fully supported by dependabot.
But with this enhancement any language and eco system can profit from dependabot. Opening issues to make developers aware of new versions and allow to track progress is already incredibly useful.

Compared to adding new ecosystems, this feature request can be implemented much easier. At the same time every unsupported and even supported ecosystem with complex requirements (as #2242 shows) profits from this.

[jeffwidman]

👋 Thanks for the suggestion.

A couple of thoughts:

1. identifying new releases is difficult, if it was just creating the PR then yes, this might be doable, but figuring out that we need to bump something is half the battle.
2. The focus of dependabot-core (this repo and its issue tracker) is on shelling out to native package managers, feeding them the necessary inputs, then letting them generate the diffs and we turn that into a PR. I don't see the point of opening an issue when a package manager gives us a diff... why not turn that into a PR?
3. Long term, the idea of trying to become a platform that allows external contributors to write/maintain plugins of some fashion or another to support their favorite ecosystem (but without creating a maintenance burden on the core team) is very much on our minds... that'd be the better long term way to get at "support the long tail of ecosystems". It's a thorny problem, so while we have some hand-wavy ideas, nothing is concrete yet and nothing that will ship in the immediate future.

I'm going to close this because the suggested solution is a wontfix, but the underlying problem is absolutely correct, just we already have other tickets tracking it.

[Leon0402]

@jeffwidman I'm tagging you, because I'm not quite sure you would otherwise see this. Hope this is okay. I wanted to respond to the thoughts.

Based on your thoughts, I realized that my propasal wasn't thought through completly. My propsal / wish / hope would be that dependabot would work for a lot of environments without knowing anything specific about their package manager. So a mode that could be used for many languages without actually understanding them.

So this raises the first question: How would dependabot know what dependencies a project has and how would it find new released of it? I think this is the point I missed in my proposal, because I didn't thought about it. Obviously given a completly unknown environment, dependabot wouldn't even know what dependencies a project has. Because as you explained normally dependabot would communicate with some package manager and that package manager gives all information needed.

I can think of only one solution and that would be to create a new language / excosystem agnostic way of additionally specifying all the projects dependencies.
Next question would be: Where are the dependencies from / how to know if they have to be updated. Most often they will come from some sort of registry. But that is not really applicable here, because then we would again need ecosystem specific knowledge about how these registries work (pypie, maven repository, npm, ...).
But I assume most of the packages found on the registries a backed by some repository on github or gitlab mostly. So we could use this information instead to define the format. It might looks something like this:

dependabot_deps.yaml

my_dep_1:
   provider: github
   url: <url to github repo>
   version: 1.3.0
my_dep_2: 
   provider: gitlab
   url: <url to gitlab repo>
   version: 2.5.0
....

dependabot could use the apis of github / gitlab and other common repositories to figure out new releases on that platform. In this case it could then actually do a PR to bump the version in this file (rather than filing an issue). Developers could then add a commit to bump the version in their ecosystem as well to this PR.

This is still not completly ecosystem agnostic as it assumes that all dependencies are on github or gitlab or something like this (and deps use the "Release" Feature of github / gitlab). This obviously hasn't to be the case. But I would argue that this mode would still allow to use dependabot at least partially in many ecosystems for many dependencies. The above format would for example also allow to specify a subset of deps that should be tracked or rather can be tracked.

The benefit and motivation behind this proposal is that developers are automatically reminded / informed that new releases are out. I consider this the main benefit of dependabot. If dependabot has the available information to additionally also bump the version (as it does right now) this is really nice. But I still feel the main benefit is the informing about new releases and I would really like to see a solution for all ecosystem to provide this sort of baseline functionality.

This brings me to your third point. I totally agree that supporting more native package managers is the core goal and allowing external contributions is certainly helping a lot in this. But there are two main issues:

• It's not implemented yet and more importantly it won't be any soon. So while this a great long term plan, it doesn't really help in the near future
• Even if this exists: Someone still has to actually write support for the new ecosystems (and maintain them). That can't be trivial otherwise the core team of dependabot wouldn't even need the support from the community. So it's very likely that even with this change many ecosystems will not be supported (or not maintained well).

So this propsal is more about adding a fallback mode. Which works for a lot more ecosystem and brings the main benefit of dependabot (in my opinion) to as many people as possible, but therefore lacks features that the native integration supplies.

There is still your second point "he focus of dependabot-core (this repo and its issue tracker) is on shelling out to native package managers". You're correct this proposal suggests a mode that works follows a very different idea, so it is likely a won't fix or out of scope. There are still a few points though:

• I believe the proposed approach would be too difficult to implement and maintain. Mainly because it is a very limited approach as explained above. And limited usually also means simpler to implement.
• A lot of the functionality of dependabot could be reused. So even if it's a new approach, it is not like a complete new implementation. The integration in certain platforms like github is very useful, the ability to create merge requests ...
• Dependabot already supports a "git submodule" ecosystem. I think this goes already in a very similar direction to what I have in mind here. And without knowing / understanding dependabot in detail I would also argue that the git submodule ecosystems already works very differently compared to other ecosystems. I actually even wondered if the proposal here could be some a generalization of the git submodule ecosystem. Because essentially it is a very similar approach.

So if this propsal would be better fitted in a completly new project, then this would mean that a lot of functionality that dependabot provides has to be reinvented. This is mostly in my opinion the integration of dependabot in github and gitlab (https://gitlab.com/dependabot-gitlab/dependabot), but also stuff like creating merge requests and interacting with the platform. So this is my main motivation why I would like to see such a feature in dependabot, because it would be a waste to reinvent the wheel with a completly new project.

I would be very interested to hear some thoughts about this new proposal, which is admittedly very different from the original one. Especially if you think something like this would be
a) Useful in general and could work in a similar fashion like described above
b) Something that could possibly be implemented in dependabot (perhaps by the community) now or if this is still completly against the philosophy of dependabot and thus a nonfix

[jeffwidman]

TBH, this sounds like https://xkcd.com/927/, so not something we'll put time into because the odds of success are so low... if you started it as a community project, and got a lot of adoption, then we could have a conversation about adding support for it in Dependabot. But we are more of a "add support for standards that are already popular" not "create new standards" project.