What do you think of dependabot?

[ItsDrike]

There has been quite a lot of dependabot related PRs, and it can be pretty annoying to anyone watching, or considering to watch the repo, as it fills up your notifications quite a lot, and also creates a lot of clutter PRs.

While having dependabot is nice as it allows us to always keep our dependencies up to date, do we really need that? Wouldn't just updating manually bumping everything at once with poetry update every now and then be enough? There's a few considerations here:

• Vulnerabilities in our dependencies: Turning off dependabot PRs would still produce security events if a dependabot detected a vulnerability, so we would know about it regardless.
• Allowing projects depending on mcproto to update: Other projects that use mcproto might not be able to update a dependency which we didn't yet update. For example, if we have a dependency like ^2.1.3, projects using mcproto will only be able to install this dependency at >=2.1.3,<3.0.0 . Even though 3.0.0 might already have been released. Dependabot makes sure we always remain up to date with these updates, meaning new mcproto releases will allow people to use the new versions of these dependencies. (This only affects runtime dependencies)
• Ability to immediately notice an update which breaks something: Whenever our CI workflows fail on a dependabot PR, we know that there was some breaking change that affects us in this bumped version.
• Pyright bugs, typing changes: A commonly seen dependabot PR is one which updates pyright.
  • Pyright makes a lot of releases, as new typing features are being added to python quite often. Leaving pyright unupdated for too long might become a problem if we'd like to use a new typing feature with outdated pyright.
  • Pyright also often contains bugs due to it's complex codebase, and bugfix releases are very common. It's possible pyright fixes something that uncovers a bug in our codebase, and not updating for too long might mean that during an update, we'd need to fix a bunch of these issues at once.
  • Another consideration here is that IDEs often use their own version of pyright, which will be updating regularly, so not updating here might mean that your editor will not show you the same diagnostics as what the CI will report (however pre-commit should be using pyright installed from within the virtual environment, so you would still catch it there, nevertheless this might be annoying, especially if your editor has some new bugfix which our version doesn't have, showing you an unfixed error in the codebase).
  • The library is marked as typed, and people using it will be using their own pyright version (likely latest), when utilizing it in their projects. This means there could be a fixed pyright bug now detecting something in our codebase, which our CI won't be catching. This could make some typing features of the library missing, or even worse, misleading.

Note: This will not affect dependabot settings for github workflow action bumps, this discussion is purely about using dependabot for python dependencies, action bumps will remain turned on.

[ItsDrike]

The annoyances of dependabot were greatly mitigated with #259 which introduced automatic merging of all dependabot PRs that pass the CI checks. This greatly reduces the maintaining burden of having to tediously review these PRs manually, which was the core issue of this problem.

This means this is now no longer that relevant, and while there are still some annoyances with dependabot (like the constant stream of github notifications from these PRs, or the amount of PRs that there are, which makes the issue numbers needlessly too big), these are nowhere near as important as the maintainer burden was, and I'm fine with accepting those for the benefit of having easy constant updates.