RobertCraigie / RobertCraigie/pyright-python
Pre-commit hook imports fail with pyenv venv.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 277
- Forks
- 31
- Avg merge
- 4h 22m
- Merged PRs (30d)
- 3
Description
We are using pyenv to manage our virtual environments.
I was unable to get the pre-commit hook working in a way that it could be added to our repositories. It always fails to resolve imports.
The docs directly address this here: https://github.com/RobertCraigie/pyright-python?tab=readme-ov-file#pre-commit
There one is instructed to set the venvPath and venv settings. We do not have a pytoml in our projects so I tried to configure this using the pyrightconfig.json.
{
"venvPath": "~/.pyenv/versions",
"venv": "myproject"
}
This fails in constructing the venv path and concatenates the current dir with the venvPath /home/spe/myproject/~/.pyenv/versions.
Entering a absolute path works, but then I can't commit this to our repos.
Our team does have the envs all in the same place, as that is how pyenv puts them. So it would be great if the relative home dir path would work.
When I execute pyright via CLI I can simply provide the --pythonpath argument (https://github.com/microsoft/pyright/blob/main/docs/command-line.md),
The JSON config does not have this option (https://github.com/microsoft/pyright/blob/main/docs/configuration.md#main-configuration-options).
Since the pre-commit plugin runs the CLI command, I tried adding the --pythonpath as args to the pre-commit hook definition (https://pre-commit.com/#hooks-args), but this seems to be ignored or not passed on.
I then switched to a local hook definition based on https://github.com/RobertCraigie/pyright-python/blob/main/.pre-commit-hooks.yaml.
This doesn't work as it uses the python language, which as stated by the maintainer of pre-commit, creates an isolated virtual env for the python execution (https://stackoverflow.com/a/70780205/2230045), always missing the imports.
I therefore switched to the system language, which didn't work either when the hook is executed through the VS Code source control commit dialog, as VS code does not seem to make use of the currently active venv for these executions.
What finally worked:
.pre-commit-config.yaml
repos:
- repo: local
hooks:
- id: pyright
name: pyright
description: "Python command line wrapper for pyright, a static type checker"
entry: bin/lint-pyright.sh
language: script
"types_or": [python, pyi]
require_serial: true
additional_dependencies: []
minimum_pre_commit_version: "2.9.2"
bin/lint-pyright.sh
#!/bin/bash
VENV_NAME="myproject"
eval "$(pyenv init -)" # initialize pyenv for current shell
eval "$(pyenv virtualenv-init -)" # initialize pyenv-virtualenv for current shell
pyenv shell $VENV_NAME
python -m pyright "$@"
requirements-dev.txt
pyright==1.1.359
Maybe this helps someone search for a solution.
But more importantly, maybe something could be improved:
- Properly handle the home dir shortcut
~invenvPathinpyrightconfig.json - Accept
pythonpathasargsfor the pre-commit hook - Provide
pythonPathinpyrightconfig.json - Directly accept the
venvPathandvenvarguments for the pre-commit hook - Provide a more direct way to configure the pre-commit hook to run on a virtual env.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the pre-commit hook definition in .pre-commit-hooks.yaml and the venvPath and venv behavior described for pyrightconfig.json. Reproduce the reported ~ path handling and ignored --pythonpath args, then narrow the issue to one supported configuration improvement. Done should mean the selected pre-commit setup resolves imports consistently and its behavior is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, shell
- Domain
- cli, developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100