Does prek understand files such as .nvmrc or .python-version

[hofbi]

This is a question (and optional feature request). Some languages/tools provide config files to specify their tool/language version, e.g. .python-version for uv or .nvmrc for node. Would it make sense if prek reads these versions and uses them as respective language version if not specified in the config file? This would prevent users from making sure the language version set in prek is in sync with the rest of the project.

[j178]

Thanks for raising this.

prek does not currently read .nvmrc or .python-version.

Today the supported ways to control this are:

• hook-level language_version
• top-level default_language_version
• language_version: system, if you want prek to use whatever toolchain is already selected by your shell / version manager

There is also some language-specific metadata inference, but it is not the same as reading .nvmrc / .python-version: for remote hook repositories, Python can derive a request from pyproject.toml project.requires-python or PEP 723 script metadata, and Go can derive one from go.mod. Those describe the hook package/tool itself.

I’m a bit hesitant to make prek generally read consumer project files like .nvmrc or .python-version for all hooks. Hook environments are meant to be reproducible from the hook config/manifest, and implicitly depending on arbitrary project files would affect cache identity and may be surprising, especially for remote hooks or workspaces.

[hofbi]

There is also some language-specific metadata inference, but it is not the same as reading .nvmrc / .python-version: for remote hook repositories, Python can derive a request from pyproject.toml project.requires-python or PEP 723 script metadata, and Go can derive one from go.mod. Those describe the hook package/tool itself.

What version has precedence?

1. hook-level
2. top-level
3. pyproject.toml / go.mod

Is this the correct order or how does 2) and 3) work out in reality? Does this happen automatically or would a user have to specify something to get prek look at the project files at all?

I’m a bit hesitant to make prek generally read consumer project files like .nvmrc or .python-version for all hooks. Hook environments are meant to be reproducible from the hook config/manifest, and implicitly depending on arbitrary project files would affect cache identity and may be surprising, especially for remote hooks or workspaces.

I fully understand your concerns. From a reproducibility level, I would also be in favor of being explicit about that, e.g that a user would explicitly say that they want to read the version form the file. Something like

default_language_version:
    python: "3.12"
    python_version_file: ".python-version"

I know changing/adding new contracts to the manifest is always tricky. I just wanted to brainstorm if there would be good ways to implement this.