Disable dependabot PRs

[jcushman]

Related to #11, I don't think it makes sense to pull in dependabot pull requests like this one for lxml. The minimum lxml version doesn't want to be 4.6.3, it wants to be whatever minimum version works.

The dependabot updates marked "[security]" might make sense to pull in? Even there I might be tempted to eyeball them and see if the security issue is relevant ... but on the other hand any github project that depends on eyecite will get the same security update prompt, so maybe fine to use those ones to set minimum requirements anyway.

[mlissner]

Hm, I have a lot of thoughts here, but is the version bump on stuff like this causing you trouble as a user of the library?

[jcushman]

It hasn't yet caused problems, but I do think it's likely to. CAP currently has 446 transitive dependencies, of which 89 specify maximum versions (looking at pipdeptree | wc -l and pipdeptree | grep "<" | wc -l). So if we have a dependency that says "hey I come with four or five sub-dependencies and I refuse to run with anything but the latest minor version of any of them," I'd expect that dependency to be uninstallable sometimes -- it's just not that unusual for another package to say "oh we're not actually compatible with lxml 4.6 yet because of some unfixed regression," which is fine as long as eyecite admits it can run on 4.5. One library can get away with not doing this, but the whole situation only works because most libraries are liberal in the range they allow.

I think it's totally necessary to pin precise versions of everything for web projects (though personally I've found fewer compatibility problems in the Django ecosystem when pinning versions six months or a year back for non-security updates, rather than updating right away). But I don't see the benefit of a library requiring the latest minor version of its deps.

[mlissner]

Yeah, that logic holds up with the caveat you mentioned around security. Thanks for educating me on that. I'll turn off dependabot except for security upgrades. Gonna have to do that for a lot of projects to change over to that logic.

[mlissner]

For now, I'm not downgrading the deps because that's a bit more of a pain, but we can go for that if any conflicts arise.