Support for bumping pyright version using dependabot

[jenshnielsen]

Thanks for a great action,

It would be nice to be able to pin the pyright version used but have in automatically upgraded. Would it be possible to specify the version of pyright in a package.json file or similar such that dependabot or similar tool automatically can update the version when a new pyrigth version is released. Could this be possible?

[jakebailey]

That's an interesting idea, though I don't quite know I feel about Python projects sticking package.json and package-lock.json into their repos and then not using them for anything but pyright.

It doesn't look like dependabot is adding any new ecosystems either, so I don't have the opportunity to encode this elsewhere.

Maybe it'd be possible to pin via the pyright PyPI package (and detect that it's already installed in PATH), if that's something you might find more reasonable.

[jenshnielsen]

@jakebailey I guess that could work. I have been trying to avoid using the pip version to not pull in an extra node environment within my pip install.

I don't quite know I feel about Python projects sticking package.json and package-lock.json into their repos and then not using them for anything but pyright.

Agree that's not the greatest. It would be better if the files could have a less generic name. As a partial mitigation I guess its possible to have the file in another location than the root to make this less confusing such as .github/pyright/package.json ?
This should work since dependabot can be configured to look in multipel directories

[jakebailey]

Sticking a package.json into .github could work. One immediate trouble I can imagine is that the version specified in the option currently is an exact version (or latest), but package.json would be semver, so I'd need to decide what to do about that, as well as what do about lock files.

[jenshnielsen]

Yes, I would expect the user want to specify the full version since it in my experience is fairly common for typechecking to change between 2 patch versions causing new errors

[jakebailey]

I've been playing around with renovate; one thing it supports is a way to annotate parts of files to indicate that they are in fact package versions. I think one can do this:

env:
  # renovate: datasource=npm depName=pyright
  PYRIGHT_VERSION: '1.1.311'

- uses: jakebailey/pyright-action@v1
  with:
    version: ${{ env.PYRIGHT_VERSION }}

Then add the regexManagers:githubActionsVersions preset to a renovate config.

• https://docs.renovatebot.com/presets-regexManagers/#regexmanagersgithubactionsversions
• https://docs.renovatebot.com/modules/manager/regex/

[jakebailey]

That preset only works for vars that end in _VERSION, but here's a working example:

• https://github.com/jakebailey/pyright-action-renovate-test
• Update dependency pyright to v1.1.393 pyright-action-renovate-test#4

If one opts for copying the preset and modifying it to work on the version: line, that would work too, but an env var is okay.

[Avasam]

It doesn't look like dependabot is adding any new ecosystems either, so I don't have the opportunity to encode this elsewhere.

Looks like this is now Contributing new ecosystems

[jakebailey]

Yeah, though I'm not totally sure what it'd look like 😄

I'm tempted to just add support for reading the version out of a package.json, as originally suggested. That's what we do in TypeChat: https://github.com/microsoft/TypeChat/blob/main/python/package.json#L12

[ewjoachim]

So, just wanted to weight in: I'm using this action, and also the pre-commit hook from https://github.com/RobertCraigie/pyright-python (the python package wrapper over the pyright package, that is listed in the pyright doc as the way to go.

Do you think there could be a way to ensure that the pyright version used by both system is the same AND is updated by renovate/dependabot ? Given the way pre-commit works, I'm enclined to say the only way I see would be to extract the version from pre-commit with:

$ yq '.repos | filter(.repo == "https://github.com/RobertCraigie/pyright-python").0.rev | "pyright-version="+sub("^v", "")' >> $GITHUB_OUTPUT

(yq is pre-installed on GHA)

So I'd need a step for that, and then use

- uses: jakebailey/pyright-action@v1
  with:
    version: ${{ steps.<id>.outputs.pyright-version }}

Is there a better way or should this be the way ? If so, should it be documented as such ?

[jakebailey]

As more projects keep pinning pyright using different mechanisms (package.json, requirements.txt, pyproject, precommit), I'm less included to try and include something here just becuase it sounds like a slippery slope of every format that could exist.

I have no problem with providing examples in the README using the different methods, though.

[jenshnielsen]

@jakebailey Given that you now support using an installed version from PATH (and thanks for that) I think we can safely close this issue. The user is free to manage installation of pyright in a way that they see fit, which can then be updated using dependabot or a similar tool

[jakebailey]

Yes, I agree!

There is still #98, where parsing a version and passing it in may still be valuable, but I think the verison: PATH method is not too bad if you're willing to pull in the PyPI package.

[jenshnielsen]

@jakebailey FYI installing the version via NPM should also work fine. Here is an example that I hacked together of doing that microsoft/Qcodes#5958

[jakebailey]

Indeed; though I largely think parsing it is going to be faster, slightly. I have this in TypeChat: https://github.com/microsoft/TypeChat/blob/f53b971179d0136424a75d67287903a2421af98b/.github/workflows/ci.python.yml#L52

[jenshnielsen]

@jakebailey Thanks for the tip. That is indeed a lot simpler and nicer