Skip to content

3.11.0a3: under tox, sys._base_executable is wrong #90186

Closed
Closed
3.11.0a3: under tox, sys._base_executable is wrong#90186
Labels
3.11only security fixes

Description

@nedbat
nedbat
opened on Dec 10, 2021
BPO 46028
Nosy @vsajip, @vstinner, @tiran, @nedbat, @zooba, @pablogsal, @saaketp
PRs
  • bpo-46028: Calculate base_executable by resolving symlinks in a venv #30144
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = None
created_at = <Date 2021-12-10.00:24:21.754>
labels = ['3.11']
title = '3.11.0a3: under tox, sys._base_executable is wrong'
updated_at = <Date 2022-01-18.15:47:49.048>
user = 'https://github.com/nedbat'

    bugs.python.org fields:

    activity = <Date 2022-01-18.15:47:49.048>
actor = 'steve.dower'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2021-12-10.00:24:21.754>
creator = 'nedbat'
dependencies = []
files = []
hgrepos = []
issue_num = 46028
keywords = ['patch', '3.11regression']
message_count = 30.0
messages = ['408166', '408167', '408168', '408180', '408195', '408206', '408278', '408311', '408312', '408313', '408318', '408319', '408483', '408484', '408489', '408490', '408491', '408492', '408493', '408494', '408525', '408526', '408528', '408569', '408692', '408710', '408744', '410850', '410872', '410873']
nosy_count = 7.0
nosy_names = ['vinay.sajip', 'vstinner', 'christian.heimes', 'nedbat', 'steve.dower', 'pablogsal', 'saaketp']
pr_nums = ['30144']
priority = 'normal'
resolution = None
stage = 'commit review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue46028'
versions = ['Python 3.11']

    Activity

    1. nedbat commented on Dec 10, 2021

      @nedbat
      nedbat
      on Dec 10, 2021
      MemberAuthor

      Under tox, sys._base_executable is not an actual file for 3.11.0a3. It was fine in 3.11.0a2.

      To reproduce:

      --- 8< --------------------
      # tox.ini
      [tox]
      envlist = py{310,311a2,311}
      skipsdist = True

      [testenv]
      commands =
      python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))"

      [testenv:py311a2]
      # This is the path to 3.11.0a2 if you have it.
      basepython = /usr/local/pyenv/pyenv/versions/3.11.0a2/bin/python3
      ----------------------------

      Create a new Python 3.8 virtualenv, and install latest tox (3.24.4 for me).

      Then run "tox". I see:

      --------------------------------------------------------------------------------
      py310 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py310
      py310 run-test-pre: PYTHONHASHSEED='534434199'
      py310 run-test: commands[0] | python -c 'import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))'
      /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py310/bin/python
      True
      py311a2 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311a2
      py311a2 run-test-pre: PYTHONHASHSEED='534434199'
      py311a2 run-test: commands[0] | python -c 'import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))'
      /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311a2/bin/python
      True
      py311 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311
      py311 run-test-pre: PYTHONHASHSEED='534434199'
      py311 run-test: commands[0] | python -c 'import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))'
      /usr/local/pyenv/pyenv/versions/3.11.0a3/python
      False
      _________________________________________________________ summary _________________________________________________________
      py310: commands succeeded
      py311a2: commands succeeded
      py311: commands succeeded
      congratulations :)
      --------------------------------------------------------------------------------

      This came to my attention because the coverage.py test suite uses "python -m venv" to create environments. They worked under 3.11.0a2, but failed under a3. I tracked it down to a difference in sys._base_executable.

      I couldn't see a difference in those values without tox, but I'm not sure why it changes the results.

    2. nedbat
      added
      3.11only security fixes
      on Dec 10, 2021

    3. pablogsal commented on Dec 10, 2021

      @pablogsal
      pablogsal
      on Dec 10, 2021
      Member

      Steve, could this be related to the changes in getpath?

    4. pablogsal
      added
      release-blocker
      on Dec 10, 2021

    5. pablogsal commented on Dec 10, 2021

      @pablogsal
      pablogsal
      on Dec 10, 2021
      Member

      Ned, are you able to bisect this or provide a simpler reproducer that doesn't involve tox?

    6. tiran commented on Dec 10, 2021

      @tiran
      tiran
      on Dec 10, 2021
      Member

      Commit 9f2f7e4 has correct _base_executable

      $ venv/bin/python
Python 3.11.0a2+ (heads/bpo-45847-simple-115-g9f2f7e42269:9f2f7e42269, Dec 10 2021, 10:09:54) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys._base_executable
'/home/heimes/dev/python/cpython/venv/bin/python'

      _base_executable in commit 99fcf15 is wrong

      $ venv/bin/python
Python 3.11.0a2+ (heads/bpo-45847-simple-116-g99fcf150521:99fcf150521, Dec 10 2021, 10:12:35) [GCC 11.2.1 20211203 (Red Hat 11.2.1-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys._base_executable
'/home/heimes/dev/python/cpython/python'

    7. nedbat commented on Dec 10, 2021

      @nedbat
      nedbat
      on Dec 10, 2021
      MemberAuthor

      git bisect also identifies that commit as the first bad:

      99fcf15 is the first bad commit
      commit 99fcf15
      Author: Steve Dower <steve.dower@python.org>
      Date: Fri Dec 3 00:08:42 2021 +0000

      bpo-45582: Port getpath[p].c to Python (GH-29041)

The getpath.py file is frozen at build time and executed as code over a namespace. It is never imported, nor is it meant to be importable or reusable. However, it should be easier to read, modify, and patch than the previous code.

This commit attempts to preserve every previously tested quirk, but these may be changed in the future to better align platforms.

    8. pablogsal commented on Dec 10, 2021

      @pablogsal
      pablogsal
      on Dec 10, 2021
      Member

      Indeed, seems my original hunch is correct. Steve, could you take a look when you have some time?

    9. zooba commented on Dec 11, 2021

      @zooba
      zooba
      on Dec 11, 2021
      Member

      I'm going to need a decent amount of time to learn all of these components, because I never use this OS, Tox, nor virtualenv :) I'll try and get to it, but don't hold your breath. Luckily, Modules/getpath.py is much easier to follow and modify than the old systems.

      If there's a pyvenv.cfg involved, base_executable should be calculated based on the "home" key in it. Previously, I don't think we calculated it at all on Linux - it was just sys.executable before site.py changes anything.

      On Windows, it was always intended to be "the executable that new venvs should be created with" so that venvs created from venvs would be based off the same install, rather than trying to chain. I have no idea what the correct path for that is in this context, so could do with some help.

    10. nedbat commented on Dec 11, 2021

      @nedbat
      nedbat
      on Dec 11, 2021
      MemberAuthor

      Tox isn't needed, just venv from the stdlib:

      $ python3.11.0a2 -m venv venv_a2

$ venv_a2/bin/python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))"
/private/tmp/venv_a2/bin/python
True

$ python3.11.0a3 -m venv venv_a3

$ venv_a3/bin/python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))"
/usr/local/bin/python
False

    11. zooba commented on Dec 11, 2021

      @zooba
      zooba
      on Dec 11, 2021
      Member

      What's the contents of the pyvenv.cfg in these cases?

      It looks like the first case is definitely wrong, because the base
      executable should not be in "venv_a2" (that's sys.executable), but I
      don't know where it should be on your system.

    12. nedbat commented on Dec 11, 2021

      @nedbat
      nedbat
      on Dec 11, 2021
      MemberAuthor

      The two venvs seem analogous:

      $ cat venv_a2/pyvenv.cfg
home = /usr/local/bin
include-system-site-packages = false
version = 3.11.0

$ ls -al venv_a2/bin
total 72
drwxr-xr-x  13 nedbatchelder  wheel   416 Dec 11 10:43 ./
drwxr-xr-x   6 nedbatchelder  wheel   192 Dec 11 10:43 ../
-rw-r--r--   1 nedbatchelder  wheel  9033 Dec 11 10:43 Activate.ps1
-rw-r--r--   1 nedbatchelder  wheel  1993 Dec 11 10:43 activate
-rw-r--r--   1 nedbatchelder  wheel   919 Dec 11 10:43 activate.csh
-rw-r--r--   1 nedbatchelder  wheel  2061 Dec 11 10:43 activate.fish
-rwxr-xr-x   1 nedbatchelder  wheel   244 Dec 11 10:43 pip*
-rwxr-xr-x   1 nedbatchelder  wheel   244 Dec 11 10:43 pip3*
-rwxr-xr-x   1 nedbatchelder  wheel   244 Dec 11 10:43 pip3.11*
lrwxr-xr-x   1 nedbatchelder  wheel    14 Dec 11 10:43 python@ -> python3.11.0a2
lrwxr-xr-x   1 nedbatchelder  wheel    14 Dec 11 10:43 python3@ -> python3.11.0a2
lrwxr-xr-x   1 nedbatchelder  wheel    14 Dec 11 10:43 python3.11@ -> python3.11.0a2
lrwxr-xr-x   1 nedbatchelder  wheel    29 Dec 11 10:43 python3.11.0a2@ -> /usr/local/bin/python3.11.0a2

$ cat venv_a3/pyvenv.cfg
home = /usr/local/bin
include-system-site-packages = false
version = 3.11.0

$ ls -al venv_a3/bin
total 72
drwxr-xr-x  13 nedbatchelder  wheel   416 Dec 11 10:43 ./
drwxr-xr-x   6 nedbatchelder  wheel   192 Dec 11 10:43 ../
-rw-r--r--   1 nedbatchelder  wheel  9033 Dec 11 10:43 Activate.ps1
-rw-r--r--   1 nedbatchelder  wheel  1993 Dec 11 10:43 activate
-rw-r--r--   1 nedbatchelder  wheel   919 Dec 11 10:43 activate.csh
-rw-r--r--   1 nedbatchelder  wheel  2061 Dec 11 10:43 activate.fish
-rwxr-xr-x   1 nedbatchelder  wheel   244 Dec 11 10:43 pip*
-rwxr-xr-x   1 nedbatchelder  wheel   244 Dec 11 10:43 pip3*
-rwxr-xr-x   1 nedbatchelder  wheel   244 Dec 11 10:43 pip3.11*
lrwxr-xr-x   1 nedbatchelder  wheel    14 Dec 11 10:43 python@ -> python3.11.0a3
lrwxr-xr-x   1 nedbatchelder  wheel    14 Dec 11 10:43 python3@ -> python3.11.0a3
lrwxr-xr-x   1 nedbatchelder  wheel    14 Dec 11 10:43 python3.11@ -> python3.11.0a3
lrwxr-xr-x   1 nedbatchelder  wheel    29 Dec 11 10:43 python3.11.0a3@ -> /usr/local/bin/python3.11.0a3

    13. saaketp commented on Dec 11, 2021

      @saaketp
      saaketpmannequin
      on Dec 11, 2021
      Mannequin

      I tried the same stuff as nedbat on WSL2, and I see similar change in the path of sys._base_executable (though I get a different "base" path on a3, so the path exists even there).

      $ ~/.pyenv/versions/3.11.0a2/bin/python -m venv venv_a2
$ ~/.pyenv/versions/3.11.0a3/bin/python -m venv venv_a3
$ venv_a2/bin/python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))"
/home/ss/venv_a2/bin/python
True

$ venv_a3/bin/python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))"
/home/ss/.pyenv/versions/3.11.0a3/bin/python
True

$ cat venv_a2/pyvenv.cfg
home = /home/ss/.pyenv/versions/3.11.0a2/bin
include-system-site-packages = false
version = 3.11.0

$ cat venv_a3/pyvenv.cfg
home = /home/ss/.pyenv/versions/3.11.0a3/bin
include-system-site-packages = false
version = 3.11.0

    14. 13 remaining items

    15. zooba commented on Dec 14, 2021

      @zooba
      zooba
      on Dec 14, 2021
      Member

      $ v311/bin/python -m venv 311-nested
      Error: [Errno 2] No such file or directory: '/private/tmp/bpo-46028/311-nested/bin/python'

      I assume /private/tmp/bpo-46028/311-nested/bin/python3.11 exists though?
      Probably that's the issue here - I don't know how else to get the real
      executable *name* other than copying from argv[0], and it isn't supposed
      to be necessary.

      You also have v311/bin/python3.11, right? If you use that one, does it
      work? I'm trying to narrow down where the base executable is actually
      being launched and why.

    16. zooba
      changed the title [-]3.11.0a3: sys._base_executable is wrong, breaks venv - it wasn't under 3.11.0a2[/-] [+]3.11.0a3: under tox, sys._base_executable is wrong[/+] on Dec 14, 2021
    17. zooba
      changed the title [-]3.11.0a3: sys._base_executable is wrong, breaks venv - it wasn't under 3.11.0a2[/-] [+]3.11.0a3: under tox, sys._base_executable is wrong[/+] on Dec 14, 2021

    18. zooba commented on Dec 14, 2021

      @zooba
      zooba
      on Dec 14, 2021
      Member

      Or possibly that error is coming from the attempt to copy it? And since
      both executable and base_executable don't have the 3/3.x suffix, the
      copy is failing because the "real" binary does have the suffix.

      This could be corrected in getpath.py with a platform-specific quirk
      that searches for suffixed binaries for base_executable, but for
      performance reasons I think we'd prefer to have that check in venv so
      that it doesn't impact every single launch of CPython.

      The actual binary could also be added to pyvenv.cfg as another value -
      parsing that out in getpath.py is now considerably easier for someone to
      add than it used to be.

    19. nedbat commented on Dec 14, 2021

      @nedbat
      nedbat
      on Dec 14, 2021
      MemberAuthor

      I assume /private/tmp/bpo-46028/311-nested/bin/python3.11 exists though?

      Yes, that file exists, but it's a symlink to a non-existent file:

      $ ls -al 311-nested/bin
total 0
drwxr-xr-x  5 nedbatchelder  wheel  160 Dec 13 18:04 ./
drwxr-xr-x  6 nedbatchelder  wheel  192 Dec 13 18:04 ../
lrwxr-xr-x  1 nedbatchelder  wheel   21 Dec 13 18:04 python@ -> /usr/local/bin/python
lrwxr-xr-x  1 nedbatchelder  wheel    6 Dec 13 18:04 python3@ -> python
lrwxr-xr-x  1 nedbatchelder  wheel    6 Dec 13 18:04 python3.11@ -> python
$ ls -al /usr/local/bin/python
ls: /usr/local/bin/python: No such file or directory

    20. zooba commented on Dec 14, 2021

      @zooba
      zooba
      on Dec 14, 2021
      Member

      Does the first venv's 'python' link to python3[.11]? If so, maybe _base_executable should be based on real_executable's filename rather than executable (that is, *after* resolving symlinks rather than before).

      I don't *think* that will cause any issues, and it shouldn't be any more expensive to compute. Only has to change for when a pyvenv.cfg is detected I think.

    21. nedbat commented on Dec 16, 2021

      @nedbat
      nedbat
      on Dec 16, 2021
      MemberAuthor

      Here's the experiment again with 3.10.1 and 3.11.0a3, and more ls's:

      $ python3.10 -V
Python 3.10.1

$ python3.10 -m venv v310

$ ls -al v310/bin
total 72
drwxr-xr-x  12 nedbatchelder  wheel   384 Dec 16 06:42 ./
drwxr-xr-x   6 nedbatchelder  wheel   192 Dec 16 06:42 ../
-rw-r--r--   1 nedbatchelder  wheel  9033 Dec 16 06:42 Activate.ps1
-rw-r--r--   1 nedbatchelder  wheel  1993 Dec 16 06:42 activate
-rw-r--r--   1 nedbatchelder  wheel   919 Dec 16 06:42 activate.csh
-rw-r--r--   1 nedbatchelder  wheel  2061 Dec 16 06:42 activate.fish
-rwxr-xr-x   1 nedbatchelder  wheel   246 Dec 16 06:42 pip*
-rwxr-xr-x   1 nedbatchelder  wheel   246 Dec 16 06:42 pip3*
-rwxr-xr-x   1 nedbatchelder  wheel   246 Dec 16 06:42 pip3.10*
lrwxr-xr-x   1 nedbatchelder  wheel    10 Dec 16 06:42 python@ -> python3.10
lrwxr-xr-x   1 nedbatchelder  wheel    10 Dec 16 06:42 python3@ -> python3.10
lrwxr-xr-x   1 nedbatchelder  wheel    25 Dec 16 06:42 python3.10@ -> /usr/local/bin/python3.10

$ ls -al /usr/local/bin/python3.10
lrwxr-xr-x  1 nedbatchelder  admin  53 Dec 16 06:38 /usr/local/bin/python3.10@ -> /usr/local/pyenv/pyenv/versions/3.10.1/bin/python3.10

$ v310/bin/python -m venv v310-nested

$ v310-nested/bin/python -V
Python 3.10.1

$ ls -al v310-nested/bin
total 72
drwxr-xr-x  12 nedbatchelder  wheel   384 Dec 16 06:43 ./
drwxr-xr-x   6 nedbatchelder  wheel   192 Dec 16 06:43 ../
-rw-r--r--   1 nedbatchelder  wheel  9033 Dec 16 06:43 Activate.ps1
-rw-r--r--   1 nedbatchelder  wheel  2014 Dec 16 06:43 activate
-rw-r--r--   1 nedbatchelder  wheel   940 Dec 16 06:43 activate.csh
-rw-r--r--   1 nedbatchelder  wheel  2082 Dec 16 06:43 activate.fish
-rwxr-xr-x   1 nedbatchelder  wheel   249 Dec 16 06:43 pip*
-rwxr-xr-x   1 nedbatchelder  wheel   249 Dec 16 06:43 pip3*
-rwxr-xr-x   1 nedbatchelder  wheel   249 Dec 16 06:43 pip3.10*
lrwxr-xr-x   1 nedbatchelder  wheel    37 Dec 16 06:43 python@ -> /private/tmp/bpo46028/v310/bin/python
lrwxr-xr-x   1 nedbatchelder  wheel     6 Dec 16 06:43 python3@ -> python
lrwxr-xr-x   1 nedbatchelder  wheel     6 Dec 16 06:43 python3.10@ -> python

$ ls -al /private/tmp/bpo46028/v310/bin/python
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 06:42 /private/tmp/bpo46028/v310/bin/python@ -> python3.10


$ python3.11 -V
Python 3.11.0a3

$ python3.11 -m venv v311

$ ls -al v311/bin
total 72
drwxr-xr-x  12 nedbatchelder  wheel   384 Dec 16 06:45 ./
drwxr-xr-x   6 nedbatchelder  wheel   192 Dec 16 06:45 ../
-rw-r--r--   1 nedbatchelder  wheel  9033 Dec 16 06:45 Activate.ps1
-rw-r--r--   1 nedbatchelder  wheel  1993 Dec 16 06:45 activate
-rw-r--r--   1 nedbatchelder  wheel   919 Dec 16 06:45 activate.csh
-rw-r--r--   1 nedbatchelder  wheel  2061 Dec 16 06:45 activate.fish
-rwxr-xr-x   1 nedbatchelder  wheel   246 Dec 16 06:45 pip*
-rwxr-xr-x   1 nedbatchelder  wheel   246 Dec 16 06:45 pip3*
-rwxr-xr-x   1 nedbatchelder  wheel   246 Dec 16 06:45 pip3.11*
lrwxr-xr-x   1 nedbatchelder  wheel    10 Dec 16 06:45 python@ -> python3.11
lrwxr-xr-x   1 nedbatchelder  wheel    10 Dec 16 06:45 python3@ -> python3.11
lrwxr-xr-x   1 nedbatchelder  wheel    25 Dec 16 06:45 python3.11@ -> /usr/local/bin/python3.11

$ ls -al /usr/local/bin/python3.11
lrwxr-xr-x  1 nedbatchelder  admin  55 Dec  9 12:23 /usr/local/bin/python3.11@ -> /usr/local/pyenv/pyenv/versions/3.11.0a3/bin/python3.11

$ v311/bin/python -m venv v311-nested
Error: [Errno 2] No such file or directory: '/private/tmp/bpo46028/v311-nested/bin/python'

$ ls -al v311-nested/bin
total 0
drwxr-xr-x  5 nedbatchelder  wheel  160 Dec 16 06:45 ./
drwxr-xr-x  6 nedbatchelder  wheel  192 Dec 16 06:45 ../
lrwxr-xr-x  1 nedbatchelder  wheel   21 Dec 16 06:45 python@ -> /usr/local/bin/python
lrwxr-xr-x  1 nedbatchelder  wheel    6 Dec 16 06:45 python3@ -> python
lrwxr-xr-x  1 nedbatchelder  wheel    6 Dec 16 06:45 python3.11@ -> python

$ ls -al /usr/local/bin/python
ls: /usr/local/bin/python: No such file or directory

    22. zooba commented on Dec 16, 2021

      @zooba
      zooba
      on Dec 16, 2021
      Member

      This PR *might* be a fix, but I think it's only partial. It isn't going to work if you've made a venv and copied "python3"->"python", for example.

      It still might be best solved by writing base_executable into pyvenv.cfg, and then simply reading it out.

    23. nedbat commented on Dec 17, 2021

      @nedbat
      nedbat
      on Dec 17, 2021
      MemberAuthor

      Thanks, your change looks good. The exact symlinks in the nested venv's are different for 3.10.1 and your 3.11, but they both work:

      $ python3.10 -c "import sys; print(sys.version)"
3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)]

$ python3.10 -m venv v310

$ ls -al v310/bin/py*
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 18:48 v310/bin/python@ -> python3.10
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 18:48 v310/bin/python3@ -> python3.10
lrwxr-xr-x  1 nedbatchelder  wheel  25 Dec 16 18:48 v310/bin/python3.10@ -> /usr/local/bin/python3.10

$ v310/bin/python -m venv v310-nested

$ ls -al v310-nested/bin/py*
lrwxr-xr-x  1 nedbatchelder  wheel  37 Dec 16 18:48 v310-nested/bin/python@ -> /private/tmp/bpo46028/v310/bin/python
lrwxr-xr-x  1 nedbatchelder  wheel   6 Dec 16 18:48 v310-nested/bin/python3@ -> python
lrwxr-xr-x  1 nedbatchelder  wheel   6 Dec 16 18:48 v310-nested/bin/python3.10@ -> python

      $

      $ python3.11 -c "import sys; print(sys.version)"
3.11.0a3+ (heads/pr/30144:8b260a8606, Dec 16 2021, 14:31:40) [Clang 12.0.0 (clang-1200.0.32.29)]

$ python3.11 -m venv v311

$ ls -al v311/bin/py*
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 18:50 v311/bin/python@ -> python3.11
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 18:50 v311/bin/python3@ -> python3.11
lrwxr-xr-x  1 nedbatchelder  wheel  25 Dec 16 18:50 v311/bin/python3.11@ -> /usr/local/bin/python3.11

$ v311/bin/python -m venv v311-nested

$ ls -al v311-nested/bin/py*
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 18:50 v311-nested/bin/python@ -> python3.11
lrwxr-xr-x  1 nedbatchelder  wheel  10 Dec 16 18:50 v311-nested/bin/python3@ -> python3.11
lrwxr-xr-x  1 nedbatchelder  wheel  33 Dec 16 18:50 v311-nested/bin/python3.11@ -> /usr/local/cpython/bin/python3.11

    24. vstinner commented on Jan 18, 2022

      @vstinner
      vstinner
      on Jan 18, 2022
      Member

      See also: https://discuss.python.org/t/virtual-environments-vs-nix-python-upgrades/12588 "Virtual environments vs. *nix Python upgrades".

    25. zooba commented on Jan 18, 2022

      @zooba
      zooba
      on Jan 18, 2022
      Member

      New changeset 7407fe4 by Steve Dower in branch 'main':
      bpo-46028: Calculate base_executable by resolving symlinks in a venv (GH-30144)
      7407fe4

    26. zooba commented on Jan 18, 2022

      @zooba
      zooba
      on Jan 18, 2022
      Member

      Merged my PR, but I want to leave this open in commit review for now - I'm not sure it deals with all the issues here, and probably not everything from the Discourse thread linked by Victor (though it might come close).

    27. ezio-melotti
      transferred this issue fromon Apr 10, 2022

    28. zooba commented on Aug 25, 2022

      @zooba
      zooba
      on Aug 25, 2022
      Member

      I'm going to assume that since we made it to RC without further comment, the change I made fixes it.

      If not, I guess 3.11 is going to be the dividing line where the behaviour changed...

    29. zooba
      closed this as completedon Aug 25, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.11only security fixes

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions