Unpin versions for CI tools

[avylove]

In order to avoid stale tools and to catch issues early, CI tools should pull the latest version.

This removes version pinning for dev and CI tools and fixes typing errors raised in newer versions of mypy.

[squirrelsc]

Let's merge it next Monday.

[LiliDeng]

@squirrelsc is it right time to merge it? any testing need to do done before merging it?

[squirrelsc]

@squirrelsc is it right time to merge it? any testing need to do done before merging it?

It's ok to merge it today or next week.

[squirrelsc]

We can upgrade versions of tool, but not unpin them. The CI pipeline is being broken by flake8 upgrading.

[avylove]

We can upgrade versions of tool, but not unpin them. The CI pipeline is being broken by flake8 upgrading.

I don't see how the internal CI pipeline is related, the version used there hasn't changed. It's best to unpin so these things get caught early. Otherwise you have what we currently have with out-of-date validation tools.

[squirrelsc]

We can upgrade versions of tool, but not unpin them. The CI pipeline is being broken by flake8 upgrading.

I don't see how the internal CI pipeline is related, the version used there hasn't changed. It's best to unpin so these things get caught early. Otherwise you have what we currently have with out-of-date validation tools.

I haven't said it happened on internal CI pipelines. But if we use the same way to unpin upstream packages in internal pipelines, that will happen someday. And we need to comeback to discuss and investigate in holidays again. The flake8 issue is more like a regression, instead of a new feature. It blocks me to merge some PRs. Even flake8 brings a new validation, it applies to existing code as a debt, which should be fixed by maintainers, instead of current PRs' contributors. I have to wait it's fixed. Out-of-date validation tools are cost, which can be accepted, but build breaks are not.

[avylove]

We can upgrade versions of tool, but not unpin them. The CI pipeline is being broken by flake8 upgrading.

I don't see how the internal CI pipeline is related, the version used there hasn't changed. It's best to unpin so these things get caught early. Otherwise you have what we currently have with out-of-date validation tools.

I haven't said it happened on internal CI pipelines. But if we use the same way to unpin upstream packages in internal pipelines, that will happen someday. And we need to comeback to discuss and investigate in holidays again. The flake8 issue is more like a regression, instead of a new feature. It blocks me to merge some PRs. Even flake8 brings a new validation, it applies to existing code as a debt, which should be fixed by maintainers, instead of current PRs' contributors. I have to wait it's fixed. Out-of-date validation tools are cost, which can be accepted, but build breaks are not.

It's all one in the same and unpinning has the lowest maintenance cost. What you're describing is signal, which is what we want. If someone submits a PR and gets and error unrelated to their PR, they should be able to identify it. We fix it quickly or pin temporarily. The alternative is we need to come up with a system to automatically generate PRs for the next version. It's too much work to do that way which is why the standard way is to have no upper bound pinning.

[avylove]

Closing this since it's now handled by BumpDeps.
Typing changes for newer versions of MyPY merged into #2545