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.

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

Added fallback to system executable #1797

Merged
merged 1 commit into from
Feb 7, 2021
Merged

Added fallback to system executable #1797

merged 1 commit into from
Feb 7, 2021

Conversation

rharish101
Copy link
Contributor

@rharish101 rharish101 commented Jan 29, 2021

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 pyenv doesn't find an executable for the current version/virtualenv, then this searches the "system" version as a fallback. Here's a motivating use case:

Black case

I have several Black's installations:

1. global by `brew install black`

2. project-specific by `pip install black`

And if I try to run black out of projects directories, I see the error:

~ black
pyenv: black: command not found

The `black' command exists in these Python versions:
  3.6.3/envs/a
  3.6.3/envs/b
  3.6.5/envs/c
  3.7.0/envs/d
  3.7.0/envs/e
  3.7.0/envs/f
  3.7.0/envs/python-in-docker
  3.7.0/envs/g

I expect to see black running as it a system command. And this is not the same as #1204 that cares about the hierarchy of Python installations.

This issue is about if a system command has the same name as one of shims commands have, then it won't be executed when it's not available in the current Python environment.

Does it make sense?

Originally posted by @extsoft in #1210 (comment)

This behaviour looks similar to one of the features added in rbenv/rbenv#1155, although I haven't gone through it properly. This is the reason why the second pre-requisite is marked.

Tests

  • My PR adds the following unit tests (if any)

If pyenv doesn't find an executable for the current version/virtualenv,
then search the "system" version as a fallback.
@anton-petrov anton-petrov self-assigned this Feb 7, 2021
@anton-petrov anton-petrov merged commit 50a4876 into pyenv:master Feb 7, 2021
@rharish101 rharish101 deleted the search_system branch February 7, 2021 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pyenv interrupt command search
2 participants