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

bpo-41538: Make python interpreter customizable for EnvBuilder #21854

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

abbec
Copy link

@abbec abbec commented Aug 13, 2020

This adds a new keyword parameter python_interpreter to
venv.EnvBuilder that lets the user customize which python to use when
creating the virtualenv, much like the virtualenv command's -p flag.

The reason that this is needed is that for some embedded cases (Blender
being one example), sys._base_executable is not set to a valid Python
executable.

https://bugs.python.org/issue41538

@abbec abbec requested a review from vsajip as a code owner August 13, 2020 11:35
@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@abbec

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Copy link
Member

@vsajip vsajip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure python_interpreter is the best name - no other sort of interpreter would be valid here, right? Perhaps you could use executable or venv_executable as the keyword argument and attribute name, as that's more commonly used to refer to a path to a Python interpreter executable (for example, sys.executable for the running interpreter).

Also, a test should be implemented for this (which would only be run if an alternative Python was available in the system path, and skipped otherwise).

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

@abbec
Copy link
Author

abbec commented Aug 18, 2020

Hi, thanks for the feedback! I have made the requested changes; please review again.

@bedevere-bot
Copy link

Thanks for making the requested changes!

@vsajip: please review the changes made to this pull request.

@@ -33,6 +33,12 @@
or sys._base_executable != sys.executable,
'cannot run venv.create from within a venv on this platform')

requireAlternativePythonInPath = unittest.skipUnless(
shutil.which("python") is not None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work if python resolves to a Python 2.x interpreter, as they don't know about Python's built-in venv (which appeared in Python 3.3). See comment below on how test should be structured.


# make sure it can be created with the alternative executable
rmtree(self.env_dir)
self.run_with_capture(venv.create, self.env_dir)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work because venv.create() won't call the builder you just created. Which makes me think:

  1. venv.create() should also have the executable keyword argument, and pass it through to the builder that it creates.
  2. The main function should parse an additional --executable argument to allow an executable to be passed in from the command line, and pass that to the builder it creates.

Also, I would suggest structuring the test as follows:

  1. Remove the requireAlternativePython decorator and function.
  2. Instead, do something along the lines of
    # create temp dir to hold venv
    found_a_python = False
    for minor in range(3, 11):
        executable = 'python3.%s' % minor
        alt_python = shutil.which(executable)
        if alt_python and alt_python != sys._base_executable:
            found_a_python = True
            # create builder with executable=alt_python
            # remove venv dir
            # create venv using the builder
            # check that venv creation appeared to work correctly
            # check that venv creation used the correct python interpreter by invoking it with
            # <venv_dir>/bin/python --version and checking what comes back is what's expected
    if not found_a_python:
        raise unittest.SkipTest('No alternative Python interpreters found for venv executable test')

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, of course, will fix!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly also add a "python3" just in case there's no "python3.X" available.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@vsajip
Copy link
Member

vsajip commented Aug 19, 2020

Actually, instead of range(3, 11) you should perhaps use range(3, sys.version_info[1] + 1). This line then shouldn't need revisiting for the rest of the 3.X series.

@abbec
Copy link
Author

abbec commented Aug 20, 2020

Actually, instead of range(3, 11) you should perhaps use range(3, sys.version_info[1] + 1). This line then shouldn't need revisiting for the rest of the 3.X series.

Yeah, will do that, thanks for the feedback.

This adds a new keyword parameter `python_interpreter` to
`venv.EnvBuilder` that lets the user customize which python to use when
creating the virtualenv, much like the virtualenv command's `-p` flag.

The reason that this is needed is that for some embedded cases (Blender
being one example), `sys._base_executable` is not set to a valid Python
executable.
This test case verifies that if you set a custom executable, it is
actually being used and the virtualenv can be created using it. Note
that this test is skipped if an alternative python can not be found in
path.
@abbec abbec force-pushed the venv-python-interpreter-issue-41538 branch from 64900d4 to 9d0a5d1 Compare January 18, 2021 10:25
@abbec
Copy link
Author

abbec commented Jan 18, 2021

Hey, sorry for the long delay but I have made the requested changes; please review again :)

@bedevere-bot
Copy link

Thanks for making the requested changes!

@vsajip: please review the changes made to this pull request.

@abbec
Copy link
Author

abbec commented Jan 18, 2021

Also, I can rebase the branch and squash the commit if you want

@abbec
Copy link
Author

abbec commented Jan 19, 2021

Will look at the build failures

@abbec abbec force-pushed the venv-python-interpreter-issue-41538 branch from 9d0a5d1 to f6d39bf Compare January 19, 2021 19:28
@abbec abbec force-pushed the venv-python-interpreter-issue-41538 branch from f6d39bf to 728781f Compare January 19, 2021 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants