issue_comments

yeah, external dependency management is a bit of a pain with pre-commit, and unfortunately that is unlikely to change.

Does pre-commit support additional_dependencies defined by the hook?

it does not complain, but I don't think it does anything with that (though I didn't verify). Also, I don't really want to issue basically empty releases just for pre-commit (even though technically feasible), so the only option I can see is indeed the status quo.

Edit: actually, no, it does make use of additional_dependencies. There's a NamedTuple that will contain all that information, and setting something in .pre-commit-config.yaml will overwrite the default values set in the hook definition.

it does not complain, but I don't think it does anything with that (though I didn't verify). Also, I don't really want to issue basically empty releases just for pre-commit (even though technically feasible), so the only option I can see is indeed the status quo.

Great, thanks for chatting about it.

Unless you meant that black should be installed together with blackdoc? If that was the question: it already is, but will only be updated together with blackdoc, so now that I think of it that might actually make pinning in blackdoc redundant?

Without pinning black in additional_dependencies, which version is used? I think the issue might be that the latest version is used based on when it's installed. But that means that different people will have different versions. And so if we pin it within blackdoc, then people can't upgrade black without a new release of blackdoc. And so we're in this spot where each user needs to pin it within their .pre-commit-config.yaml.

Does pre-commit support additional_dependencies defined by the hook? I couldn't find it in https://pre-commit.com/#creating-new-hooks. That would solve this.

Otherwise I guess you could have a bot which released a new version of blackdoc pinned to each specific version of black. But the status quo seems OK too.

Ref https://github.com/pre-commit/pre-commit/issues/2082

no, it's just that I don't think blackdoc will have a release cycle that's anything close to black's (every two months, judging by the last two releases), so unless a black release breaks blackdoc (which I hope it won't / have a CI to guard against), I think it's better to keep pinning in the user's configuration.

Unless you meant that black should be installed together with blackdoc? If that was the question: it already is, but will only be updated together with blackdoc, so now that I think of it that might actually make pinning in blackdoc redundant?

As a great fan of blackdoc, can I ask a general question re blackdoc & pre-commit? Why not have the black dependency defined in the blackdoc requirements, so it gets installed without requiring additional-dependencies?

Is ti something to do with allowing people to use an old version of black with a new version of blackdoc, such that we don't want to have too aggressive a requirement?