Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support nonexistent versions being present and set in a local .python-version #3134

Merged
merged 13 commits into from
Dec 15, 2024
Merged

Support nonexistent versions being present and set in a local .python-version #3134

merged 13 commits into from
Dec 15, 2024

Conversation

native-api
Copy link
Member

Make sure you have checked all steps below.

Prerequisite

  • Please consider implementing the feature as a hook script or plugin as a first step.
    • pyenv has some powerful support for plugins and hook scripts. Please refer to Authoring plugins for details and try to implement it as a plugin if possible.
  • Please consider contributing the patch upstream to rbenv, since we have borrowed most of the code from that project.
    • We occasionally import the changes from rbenv. In general, you can expect changes made in rbenv will be imported to pyenv too, eventually.
    • Generally speaking, we prefer not to make changes in the core in order to keep compatibility with rbenv.
  • My PR addresses the following pyenv issue (if any)

Description

  • Here are some details about my PR
  • If some of the set versions do not exist, executable resolution works without errors if an executable is found
    • as this corresponds to the current logic of selecting the first version that has the requested executable
  • pyenv local supports -f to skip existence check

Supports deployments with a version-controlled .python-version that support any of a number of Python versions

Tests

  • My PR adds the following unit tests (if any)
    Tests for added switches for pyenv local and (internal) pyenv version-name and pyenv version-file-write

@native-api native-api merged commit dc873cf into pyenv:master Dec 15, 2024
19 checks passed
@marhoy
Copy link

marhoy commented Dec 16, 2024

Thanks for the merge @native-api!

Unfortunately, this doesn't solve the problem completely.
Steps to reproduce the problem:

  1. In some pyenv-virtualenv, install a command-line utility like e.g. pre-commit or mypy, and run pyenv rehash to update the pyenv shims.
  2. There is now a corresponding shim in ~/.pyenv/shims
  3. In some other directory (outside any pyenv virtualenv): Create a .python-version which contains something that is not a pyenv virualenv (this could for instance be a project where uv is used to manage dependencies).

Running the command-line utility will now cause an exit 1 from pyenv-version-name, line 79 (caused by line 65).

I think the reason is that:

  1. The shim calls pyenv exec
  2. The shim correctly calls pyenv-version-name -f
  3. The shim calls pyenv-which
  4. pyenv-which again calls pyenv-version-name, but this time without the -f.

Thus, the solution seems to just add a -f in pyenv-which:

image

native-api added a commit that referenced this pull request Dec 16, 2024
@native-api
Tolerate nonexistent versions from pyenv-version-name in pyenv-which
86be59a 
Addendum to #3134 as per #3134 (comment)
@native-api native-api deleted the allow_nonexistent branch December 16, 2024 18:37
@native-api
Copy link
Member Author

@marhoy Done in 86be59a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Use installed version from .python-version even if not all versions are installed?
2 participants
@native-api @marhoy