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

Having two identical executables for free-threaded version is misleading #3015

Open
10 tasks done
vartec opened this issue Jul 13, 2024 · 6 comments
Open
10 tasks done

Having two identical executables for free-threaded version is misleading #3015

vartec opened this issue Jul 13, 2024 · 6 comments

Comments

@vartec
Copy link

vartec commented Jul 13, 2024

When installing Python 3.13 using the installer from Python.org, and enabling free-threading option two binaries are created:
python3.13 with free-threading disabled, and python3.13t with free-threading enabled.

When installing 3.13t-dev with pyenv, also two separate binaries are created, but with pyenv build these are exactly identical binaries, both are compiled with free-threading.

To better indicate that they are exactly the same thing this should be a symlink, alternatively python3.13 (without the t) shouldn't be there at all.

Actual:

   10 Jul 12 18:09 python -> python3.13
   10 Jul 12 18:09 python3 -> python3.13
33816 Jul 12 18:08 python3.13
33816 Jul 12 18:08 python3.13t

Expected:

   10 Jul 12 18:09 python -> python3.13t
   10 Jul 12 18:09 python3 -> python3.13t
   10 Jul 12 18:08 python3.13 -> python3.13t
33816 Jul 12 18:08 python3.13t

Alternatively python3.13 could be skipped altogether:

  10 Jul 12 18:09 python -> python3.13t
  10 Jul 12 18:09 python3 -> python3.13t
33816 Jul 12 18:08 python3.13t

This is related to #2995

Prerequisite

  • Make sure your problem is not listed in the common build problems.
  • Make sure no duplicated issue has already been reported in the pyenv issues. You should look for closed issues, too.
  • Make sure you are not asking us to help solving your specific issue.
    • GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like Gitter, StackOverflow, etc.
  • Make sure your problem is not derived from packaging (e.g. Homebrew).
    • Please refer to the package documentation for the installation issues, etc.
  • Make sure your problem is not derived from plugins.
    • This repository is maintaining pyenv and the default python-build plugin only. Please refrain from reporting issues of other plugins here.

Description

  • Platform information (e.g. Ubuntu Linux 16.04): macOS Sonoma 14.5
  • OS architecture (e.g. amd64): aarch64 (Apple M1)
  • pyenv version: 2.4.7
  • Python version: 3.13t-dev
  • C Compiler information (e.g. gcc 7.3): Apple clang version 15.0.0 (clang-1500.3.9.4)
@native-api
Copy link
Member

native-api commented Jul 13, 2024 •
edited
Loading

Both the interpreters are free-threaded. See https://github.com/orgs/pyenv/discussions/2998#discussioncomment-9919105 .

$ pyenv shell 3.14t-dev
$ python3.14t -c 'import sysconfig; print(sysconfig.get_config_var("Py_GIL_DISABLED"))'
1
$ python3.14 -c 'import sysconfig; print(sysconfig.get_config_var("Py_GIL_DISABLED"))'
1

@native-api
Copy link
Member

native-api commented Jul 13, 2024 •
edited
Loading

We did this because that's what the build produces. This is how it's supposed to be in Linux, according to @hugovk .

I doubt we'll be doing users a favor by distorting the build results -- since they'll be seeing the same result in other ecosystems.

@vartec
Copy link
Author

vartec commented Jul 13, 2024

Both the interpreters are free-threaded.

Exactly, which differs from how the Python.org installer works.

pyenv splits that into two installable versions, 3.13 and 3.13t, so IMO it should install only one interpreter, python3.13 in the former, python3.13t in the latter.

FWIW, this is not a blocker for anything, a minor nit-pick. It just had me confused to see two copies of identical interpreters.

@native-api
Copy link
Member

Exactly, which differs from how the Python.org installer works.

The key word is installer . If you check the discussion on the link, the installer contains two builds of CPython. We could do the same here, and we considered that option -- but it seems that for Linux (and for building from source in general), the upstream rather chose to provide either one or the other, and they cannot be installed alongside anyway as of now due to a bug.

@hugovk
Copy link
Contributor

hugovk commented Jul 13, 2024

@colesbury, any thoughts on this?

@colesbury
Copy link
Contributor

I think this would be better addressed upstream in CPython. We know there's some work left to do with duplicated symlinks (e.g., see Ned's comment here). Let's figure that out first.

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

No branches or pull requests
4 participants
@colesbury @hugovk @vartec @native-api