Setup dependabot for updating pyright, pytype, flake8-pyi and GitHub Actions #11564
Conversation
|
Ugh, seems like this breaks the stub-uploader, which depends on the https://github.com/python/typeshed/actions/runs/8223349890/job/22485946355?pr=11564 |
| "name": "typeshed", | ||
| "version": "0.0.0", |
There was a problem hiding this comment.
These fields are required in order for this to be considered a valid package.json file: https://docs.npmjs.com/creating-a-package-json-file#packagejson-fields
There was a problem hiding this comment.
Just FYI if you ever want to add a comment to a package.json file, just add any top level field that starts with //. ie:
"//": "my comment", "// some-packge": "other comment about a package, with a unique comment key". The "official" (as official as a mailing list can be) recommendation is to make "//" an array, but that lacks comment positioning, so I've been doing it the way I described for years.
https://groups.google.com/g/nodejs/c/NmL7jdeuw0M/m/yTqI05DRQrIJ
I fixed this failure by keeping the redundant |
|
I'm not super happy with this solution. I'd prefer to keep all meta data in one file, instead of spreading it over multiple files. I also don't think we should add a "fake" package.json file just to make dependabot happy. While it's more work, I'd prefer to use a custom solution for pyright or just keep updating it manually. |
That's definitely my preference too! But I'd also prefer to use widely used, well-tested tools for updating dependencies where possible. In this case, I personally weigh that more heavily than my preference for keeping metadata consolidated. But I agree this isn't ideal. |
| @@ -0,0 +1,29 @@ | |||
| version: 2 | |||
There was a problem hiding this comment.
Just so you know, dependabot will automatically add the dependencies label with default configs (which I believe is something we'd want, but has only been used for a single PR on typeshed before)
https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#labels
There was a problem hiding this comment.
Looks good to me. I double checked, Dependabot seems to bee looking for any file that contains the string requirements in the name or any .txt file that passes their requirements parsing test, so it should pickup ours.
https://github.com/dependabot/dependabot-core/blob/main/python/lib/dependabot/python/file_fetcher.rb
As a bonus, we could get security advisory warnings about dependencies. Although typeshed stays pretty up to date with minimal deps so we're probably gonna outpace CVE publications.
https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates
There was a problem hiding this comment.
Edit: I've been missing on conversations as my page was opened.
I'm not super happy with this solution. I'd prefer to keep all meta data in one file, instead of spreading it over multiple files. I also don't think we should add a "fake" package.json file just to make dependabot happy. While it's more work, I'd prefer to use a custom solution for pyright or just keep updating it manually.
Thoughts on using https://pypi.org/project/pyright/ ? We could then also simplify tests/pyright_test.py and scripts/runtests.py since we wouldn't need to manually check for node install anymore. Nor have to parse the pyright version.
I fixed this failure by keeping the redundant
tool.typeshed.pyright_versionfield inpyproject.tomlfor now, even though none of our tooling will actually use that field if this PR is merged. Once we've merged this PR, we can update the stub-uploader to read from thepackage.jsonfile instead, and then we can remove the redundant field from ourpyproject.tomlfile here.
^ explains why the pyproject.toml is left in for now.
Still rescinded my review for now to further discuss @srittau 's concern. But I tend to agree with Alex here if we can't find anything better.
|
I'm currently playing around with an alternative solution that uses renovate. |
|
Yeah, if you're willing to use renovate, the regex manager can bump anything anywhere: https://docs.renovatebot.com/modules/manager/regex/ [tool.typeshed]
# renovate: datasource=npm depName=pyright
pyright_version = "1.1.350"renovate ships with some presets, but you can make your own based on them, e.g. the GitHub Actions workflow scanner that looks for variables named (would have to modify a complicated regex, or just hardcode one manager for this purpose) |
|
See #11565 for what a solution using renovate might look like |
This sounds like the best solution to me. Are there potential problems with it? Otherwise, by just adding it to requirements, we'd also provide a neat way for testing locally. If this would be problematic, using renovate also sounds promising. |
Dependabot will do a daily check to see if there is a new version of pyright, pytype or flake8-pyi, and will create PRs updating them if so. It will also do a monthly check to see if there are any new versions for any of our GitHub actions, and will create a PR updating all of them together if so.
Dependabot will not check to see if any of our other dependencies are out of date. Ideally (in my opinion) it would do a monthly or quarterly check for those. Unfortunately, it doesn't look like it's possible to have two entries with different schedules for a single
package-ecosystem.In order to use dependabot with our pyright dependency, we switch to storing the pyright dependency in a minimal
package.jsonfile rather than as a field in ourpyproject.tomlfile. This is the solution suggested by @jakebailey in #11491 (comment).Fixes #11484
Closes #11491
Closes #11565