2.3.7

There was a space at the beginning of the `git clone` command

.editorconfig

@@ -0,0 +1,11 @@
+# Editor configuration, see https://editorconfig.org
+root = true
+
+[*]
+end_of_line = lf
+charset = utf-8
+
+# Makefiles always use tabs for indentation
+[Makefile]
+indent_style = tab
+indent_size = unset # Allow user-defined tab width

.github/workflows/macos_build.yml

@@ -1,5 +1,9 @@
 name: macos_build
 on: [pull_request, push]
+
+permissions:
+  contents: read  #  to fetch code (actions/checkout)
+
 jobs:
   macos_build:
     strategy:
@@ -10,6 +14,7 @@ jobs:
           - "3.8"
           - "3.9"
           - "3.10"
+          - "3.11"
     runs-on: macos-11
     steps:
       - uses: actions/checkout@v2

.github/workflows/no-response.yml

@@ -1,26 +1,30 @@
-name: No Response
-
-# Both `issue_comment` and `scheduled` event types are required for this Action
-# to work properly.
-on:
-  issue_comment:
-    types: [created]
-  schedule:
-    # Schedule for ten minutes after the hour, every hour
-    - cron: '10 * * * *'
-
-jobs:
-  noResponse:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: lee-dohm/no-response@v0.5.0
-        with:
-          token: ${{ github.token }}
-          daysUntilClose: 30
-          responseRequiredLabel: need-feedback
-          closeComment: >
-              This issue has been automatically closed because there has been no response
-              to our request for more information from the original author. With only the
-              information that is currently in the issue, we don't have enough information
-              to take action. Please reach out if you have or find the answers we need so
-              that we can investigate further.
+name: No Response
+
+# Both `issue_comment` and `scheduled` event types are required for this Action
+# to work properly.
+on:
+  issue_comment:
+    types: [created]
+  schedule:
+    # Schedule for ten minutes after the hour, every hour
+    - cron: '10 * * * *'
+
+permissions: {}
+jobs:
+  noResponse:
+    permissions:
+      issues: write  #  to update issues (lee-dohm/no-response)
+
+    runs-on: ubuntu-latest
+    steps:
+      - uses: lee-dohm/no-response@v0.5.0
+        with:
+          token: ${{ github.token }}
+          daysUntilClose: 30
+          responseRequiredLabel: need-feedback
+          closeComment: >
+              This issue has been automatically closed because there has been no response
+              to our request for more information from the original author. With only the
+              information that is currently in the issue, we don't have enough information
+              to take action. Please reach out if you have or find the answers we need so
+              that we can investigate further.

.github/workflows/pyenv_tests.yml

@@ -1,5 +1,9 @@
 name: pyenv_tests
 on: [pull_request, push]
+
+permissions:
+  contents: read  #  to fetch code (actions/checkout)
+
 jobs:
   pyenv_tests:
     strategy:

.github/workflows/ubuntu_build.yml

@@ -1,5 +1,9 @@
 name: ubuntu_build
 on: [pull_request, push]
+
+permissions:
+  contents: read  #  to fetch code (actions/checkout)
+
 jobs:
   ubuntu_build:
     strategy:
@@ -10,6 +14,7 @@ jobs:
           - "3.8"
           - "3.9"
           - "3.10"
+          - "3.11"
     runs-on: ubuntu-22.04
     steps:
       - uses: actions/checkout@v2

.gitignore

@@ -8,3 +8,5 @@
 /src/*.o
 /bats/
 /default-packages
+.idea
+*.un~

CHANGELOG.md

@@ -1,5 +1,21 @@
 ## Version History
 
+## Release 2.3.7
+
+* Add Python version 3.11 to the macOS build by @jbkkd in https://github.com/pyenv/pyenv/pull/2510
+* Don't use Zlib from XCode SDK if a custom compiler is used by @native-api in https://github.com/pyenv/pyenv/pull/2516
+* Change line endings from CRLF to LF by @hoang-himself in https://github.com/pyenv/pyenv/pull/2517
+* Fix resolution of a name that's a prefix of another name by @native-api in https://github.com/pyenv/pyenv/pull/2521
+* GitHub Workflows security hardening by @sashashura in https://github.com/pyenv/pyenv/pull/2511
+* Add nushell to activate list by @theref in https://github.com/pyenv/pyenv/pull/2524
+* Fix compilation error when building OpenSSL 1.1.1q in MacOS 11+ for 3.9.15 and 3.8.15 by @twangboy in https://github.com/pyenv/pyenv/pull/2520
+* Add simple `.editorconfig` file by @aphedges in https://github.com/pyenv/pyenv/pull/2518
+* Support `aria2c` being a snap by @native-api in https://github.com/pyenv/pyenv/pull/2528
+* Add CPython 3.12.0a2 by @saaketp in https://github.com/pyenv/pyenv/pull/2527
+* Add --no-push-path option by @isaacl in https://github.com/pyenv/pyenv/pull/2526
+* Fix typo in README.md by @weensy in https://github.com/pyenv/pyenv/pull/2535
+* Copy auto installer oneliner to readme by @spookyuser in https://github.com/pyenv/pyenv/pull/2538
+
 ## Release 2.3.6
 
 * Add CPython 3.10.8 (#2480)

COMMANDS.md

@@ -386,11 +386,12 @@ List existing pyenv shims.
 
 Configure the shell environment for pyenv
 
-    Usage: eval "$(pyenv init [-|--path] [--no-rehash] [<shell>])"
+    Usage: eval "$(pyenv init [-|--path] [--no-push-path] [--no-rehash] [<shell>])"
 
       -                    Initialize shims directory, print PYENV_SHELL variable, completions path
                            and shell function
       --path               Print shims path
+      --no-push-path       Do not push shim to the start of PATH if they're already there
       --no-rehash          Add no rehash command to output     
 
 ## `pyenv completions`

CONTRIBUTING.md

@@ -1,109 +1,109 @@
-General guidance
-================
-
-* The usual principles of respecting existing conventions and making sure that your changes
-  are in line with the overall product design apply when contributing code to Pyenv.
-
-* We are limited to Bash 3.2 features
-
-  That's because that's the version shipped with MacOS.
-  (They didn't upgrade past it and switched to Zsh because later versions
-  are covered by GPLv3 which has additional restrictions unacceptable for Apple.)
-  
-  You can still add performance optimizations etc that take advantage of newer Bash features
-  as long as there is a fallback execution route for Bash 3.
-
-* Be extra careful when submitting logic specific for the Apple Silicon platform
-
-  As of this writing, Github Actions do not support it and only one team member has the necessary hardware.
-  So we may be unable to test your changes and may have to take your word for it.
-
-
-Formatting PRs
-==============
-
-We strive to keep commit history one-concern-per-commit to keep it meaningful and easy to follow.
-If a pull request (PR) addresses a single concern (the typical case), we usually squash commits
-from it together when merging so its commit history doesn't matter.
-If however a PR addresses multiple separate concerns, each of them should be presented as a separate commit.
-Adding multiple new Python releases of the same flavor is okay with either a single or multiple commits.
-
-
-Authoring installation scripts
-==============================
-
-Adding new Python release support
----------------------------------
-
-The easiest way to add support for a new Python release is to copy the script from the previous one
-and adjust it as necessary. In many cases, just changing version numbers, URLs and hashes is enough.
-Do pay attention to other "magic numbers" that may be present in a script --
-e.g. the set of architectures and OS versions supported by a release -- since those change from time to time, too.
-
-Make sure to also copy any patches for the previous release that still apply to the new one.
-Typically, a patch no longer applies if it addresses a problem that's already fixed in the new release.
-
-For prereleases, we only create an entry for the latest prerelease in a specific version line.
-When submitting a newer prerelease, replace the older one.
-
-
-Adding version-specific fixes/patches
--------------------------------------
-
-We accept fixes to issues in specific Python releases that prevent users from using them with Pyenv.
-
-In the default configuration for a Python release, we strive to provide as close to vanilla experience as practical,
-to maintain [the principle of the least surprise](https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
-As such, any such fixes:
-
-* Must not break or degrade (e.g. disable features) the build in any of the environments that the release officially supports
-* Must not introduce incompatibilities with the vanilla release (including binary incompatibilities)
-* Should not patch things unnecessarily, to minimize the risk of the aforementioned undesirable side effects.
-  * E.g. if the fix is for a specific environment, its logic ought to only fire in this specific environment and not touch execution paths for other environments.
-  * As such, it's advisable to briefly explain in the PR what each added patch does and why it is necessary to fix the declared problem
-
-Generally, version-specific fixes belong in the scripts for the affected releases and/or patches for them -- this guarantees that their effect is limited to only those releases.
-
-<h3>Backporting upstream patches</h3>
-
-Usually, this is the easiest way to backport a fix for a problem that is fixed in a newer release.
-
-* Clone Python, check out the tag for the appropriate release and create a branch
-* Apply existing patches if there are any (with either `patch` or `git am`) and commit
-* Cherry-pick the upstream commit that fixes the problem in a newer release
-* Commit and `git format-patch`
-* Commit the generated patch file into Pyenv, test your changes and submit a PR
-
-
-Deprecation policy
-------------------
-
-We do not provide official support for EOL releases and environments or otherwise provide any kind of extended support for old Python releases.
-
-We do however accept fixes from interested parties that would allow running older, including EOL, releases in newer environments.
-In addition to the above requirements for release-specific fixes,
-
-* Such a fix must not add maintenance burden (e.g. add new logic to `python-build` that has to be kept there indefinitely)
-  * Unless the added logic is useful for both EOL and non-EOL releases. In this case, it will be considered as being primarily an improvement for non-EOL releases.
-* Support is provided on a "best effort" basis: we do not maintain these fixes but won't actively break them, either, and accept any corrections.
-  Since old releases never change, it's pretty safe to assume that the fixes will continue to work until a later version
-  of an environment introduces further incompatible changes.
-
-
-Advanced changes / adding new Python flavor support
----------------------------------------------------
-
-An installation script is sourced from `python-build`. All installation scripts are based on the same logic:
-
-1. Select the source to download and other variable parameters as needed.
-
-   This includes showing an error if the user's environment (OS, architecture) is not supported by the release.
-   Binary releases that only officially support specific distro(s) typically show a warning in other distros instead.
-
-2. Run one of the `install_*` shell functions
-
-`install_*` shell functions defined in `python-build` install Python from different kinds of sources -- compressed package (binary or source), upstream installation script, VCS checkout. Pick one that's the most appropriate for your packaging.
-
-Each of them accepts a couple of function-specific arguments which are followed by arguments that constitute the build sequence. Each `<argument>` in the build sequence corresponds to the `install_*_<argument>` function in `python-build`. Check what's available and add any functions with logic specific to your flavor if needed.
-
-We strive to keep out of `python-build` parts of build logic that are release-specific and/or tend to change abruptly between releases -- e.g. sets of supported architectures and other software's versions. This results in logic duplication between installation scripts -- but since old releases never change once released, this doesn't really add to the maintenance burden. As a rule of thumb, `python-build` can host parts of logic that are expected to stay the same for an indefinite amount of time -- for an entire Python flavor or release line.
+General guidance
+================
+
+* The usual principles of respecting existing conventions and making sure that your changes
+  are in line with the overall product design apply when contributing code to Pyenv.
+
+* We are limited to Bash 3.2 features
+
+  That's because that's the version shipped with MacOS.
+  (They didn't upgrade past it and switched to Zsh because later versions
+  are covered by GPLv3 which has additional restrictions unacceptable for Apple.)
+
+  You can still add performance optimizations etc that take advantage of newer Bash features
+  as long as there is a fallback execution route for Bash 3.
+
+* Be extra careful when submitting logic specific for the Apple Silicon platform
+
+  As of this writing, Github Actions do not support it and only one team member has the necessary hardware.
+  So we may be unable to test your changes and may have to take your word for it.
+
+
+Formatting PRs
+==============
+
+We strive to keep commit history one-concern-per-commit to keep it meaningful and easy to follow.
+If a pull request (PR) addresses a single concern (the typical case), we usually squash commits
+from it together when merging so its commit history doesn't matter.
+If however a PR addresses multiple separate concerns, each of them should be presented as a separate commit.
+Adding multiple new Python releases of the same flavor is okay with either a single or multiple commits.
+
+
+Authoring installation scripts
+==============================
+
+Adding new Python release support
+---------------------------------
+
+The easiest way to add support for a new Python release is to copy the script from the previous one
+and adjust it as necessary. In many cases, just changing version numbers, URLs and hashes is enough.
+Do pay attention to other "magic numbers" that may be present in a script --
+e.g. the set of architectures and OS versions supported by a release -- since those change from time to time, too.
+
+Make sure to also copy any patches for the previous release that still apply to the new one.
+Typically, a patch no longer applies if it addresses a problem that's already fixed in the new release.
+
+For prereleases, we only create an entry for the latest prerelease in a specific version line.
+When submitting a newer prerelease, replace the older one.
+
+
+Adding version-specific fixes/patches
+-------------------------------------
+
+We accept fixes to issues in specific Python releases that prevent users from using them with Pyenv.
+
+In the default configuration for a Python release, we strive to provide as close to vanilla experience as practical,
+to maintain [the principle of the least surprise](https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
+As such, any such fixes:
+
+* Must not break or degrade (e.g. disable features) the build in any of the environments that the release officially supports
+* Must not introduce incompatibilities with the vanilla release (including binary incompatibilities)
+* Should not patch things unnecessarily, to minimize the risk of the aforementioned undesirable side effects.
+  * E.g. if the fix is for a specific environment, its logic ought to only fire in this specific environment and not touch execution paths for other environments.
+  * As such, it's advisable to briefly explain in the PR what each added patch does and why it is necessary to fix the declared problem
+
+Generally, version-specific fixes belong in the scripts for the affected releases and/or patches for them -- this guarantees that their effect is limited to only those releases.
+
+<h3>Backporting upstream patches</h3>
+
+Usually, this is the easiest way to backport a fix for a problem that is fixed in a newer release.
+
+* Clone Python, check out the tag for the appropriate release and create a branch
+* Apply existing patches if there are any (with either `patch` or `git am`) and commit
+* Cherry-pick the upstream commit that fixes the problem in a newer release
+* Commit and `git format-patch`
+* Commit the generated patch file into Pyenv, test your changes and submit a PR
+
+
+Deprecation policy
+------------------
+
+We do not provide official support for EOL releases and environments or otherwise provide any kind of extended support for old Python releases.
+
+We do however accept fixes from interested parties that would allow running older, including EOL, releases in newer environments.
+In addition to the above requirements for release-specific fixes,
+
+* Such a fix must not add maintenance burden (e.g. add new logic to `python-build` that has to be kept there indefinitely)
+  * Unless the added logic is useful for both EOL and non-EOL releases. In this case, it will be considered as being primarily an improvement for non-EOL releases.
+* Support is provided on a "best effort" basis: we do not maintain these fixes but won't actively break them, either, and accept any corrections.
+  Since old releases never change, it's pretty safe to assume that the fixes will continue to work until a later version
+  of an environment introduces further incompatible changes.
+
+
+Advanced changes / adding new Python flavor support
+---------------------------------------------------
+
+An installation script is sourced from `python-build`. All installation scripts are based on the same logic:
+
+1. Select the source to download and other variable parameters as needed.
+
+   This includes showing an error if the user's environment (OS, architecture) is not supported by the release.
+   Binary releases that only officially support specific distro(s) typically show a warning in other distros instead.
+
+2. Run one of the `install_*` shell functions
+
+`install_*` shell functions defined in `python-build` install Python from different kinds of sources -- compressed package (binary or source), upstream installation script, VCS checkout. Pick one that's the most appropriate for your packaging.
+
+Each of them accepts a couple of function-specific arguments which are followed by arguments that constitute the build sequence. Each `<argument>` in the build sequence corresponds to the `install_*_<argument>` function in `python-build`. Check what's available and add any functions with logic specific to your flavor if needed.
+
+We strive to keep out of `python-build` parts of build logic that are release-specific and/or tend to change abruptly between releases -- e.g. sets of supported architectures and other software's versions. This results in logic duplication between installation scripts -- but since old releases never change once released, this doesn't really add to the maintenance burden. As a rule of thumb, `python-build` can host parts of logic that are expected to stay the same for an indefinite amount of time -- for an entire Python flavor or release line.

README.md

@@ -247,7 +247,9 @@ which does install native Windows Python versions.
 
 #### Automatic installer
 
-Visit our other project:
+`curl https://pyenv.run | bash`
+
+For more details visit our other project:
 https://github.com/pyenv/pyenv-installer
 
 
@@ -258,14 +260,14 @@ easy to fork and contribute any changes back upstream.
 
 * **Check out Pyenv where you want it installed.**
    A good place to choose is `$HOME/.pyenv` (but you can install it somewhere else):
-
-       git clone https://github.com/pyenv/pyenv.git ~/.pyenv
-
+    ```
+    git clone https://github.com/pyenv/pyenv.git ~/.pyenv
+    ```
 *  Optionally, try to compile a dynamic Bash extension to speed up Pyenv. Don't
    worry if it fails; Pyenv will still work normally:
-
-       cd ~/.pyenv && src/configure && make -C src
-
+    ```
+    cd ~/.pyenv && src/configure && make -C src
+    ```
 
 ### Set up your shell environment for Pyenv
 
@@ -404,21 +406,21 @@ please visit the wiki page about
 
 #### Prefix auto-resolution
 
-Pyenv automatically resolves full prefixes to the latest version in the corresponding version line.
-E.g. to install the latest 3.10 release:
+All Pyenv subcommands except `uninstall` automatically resolve full prefixes to the latest version in the corresponding version line.
+
+`pyenv install` picks the latest known version while other subcommands -- the latest installed version.
+
+E.g. to install and then switch to the latest 3.10 release:
 
 ```sh
 pyenv install 3.10
+pyenv global 3.10
 ```
 
-The same happens whenever Pyenv selects a version to use.
-Installation selects the latest version known to Pyenv
-while switching -- the latest installed version.
-
 You can run [`pyenv latest <prefix>`](COMMANDS.md#pyenv-latest) to see
 what a specific prefix would be resolved to.
 
-See the [`pyenv latest` documentation](COMMANDS.md#pyenv-latest) for details on the resolution process.
+See the [`pyenv latest` documentation](COMMANDS.md#pyenv-latest) for details.
 
 
 #### Python versions with extended support

libexec/pyenv---version

@@ -12,7 +12,7 @@
 set -e
 [ -n "$PYENV_DEBUG" ] && set -x
 
-version="2.3.6"
+version="2.3.7"
 git_revision=""
 
 if cd "${BASH_SOURCE%/*}" 2>/dev/null && git remote -v 2>/dev/null | grep -q pyenv; then

libexec/pyenv-init

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # Summary: Configure the shell environment for pyenv
-# Usage: eval "$(pyenv init [-|--path] [--no-rehash] [<shell>])"
+# Usage: eval "$(pyenv init [-|--path] [--no-push-path] [--no-rehash] [<shell>])"
 
 set -e
 [ -n "$PYENV_DEBUG" ] && set -x
@@ -9,6 +9,7 @@ set -e
 if [ "$1" = "--complete" ]; then
   echo -
   echo --path
+  echo --no-push-path
   echo --no-rehash
   echo bash
   echo fish
@@ -19,6 +20,7 @@ fi
 
 mode="help"
 no_rehash=""
+no_push_path=""
 for args in "$@"
 do
   if [ "$args" = "-" ]; then
@@ -30,6 +32,11 @@ do
     mode="path"
     shift
   fi
+
+  if [ "$args" = "--no-push-path" ]; then
+    no_push_path=1
+    shift
+  fi
   
   if [ "$args" = "--no-rehash" ]; then
     no_rehash=1
@@ -141,28 +148,56 @@ function init_dirs() {
 }
 
 function print_path() {
-  case "$shell" in
-    fish )
-      echo 'while set index (contains -i -- '\'"${PYENV_ROOT}/shims"\'' $PATH)'
-      echo 'set -eg PATH[$index]; end; set -e index'
-      echo 'set -gx PATH '\'"${PYENV_ROOT}/shims"\'' $PATH'
-      ;;
-    * )
-      # Some distros (notably Debian-based) set Bash's SSH_SOURCE_BASHRC compilation option
-      # that makes it source `bashrc` under SSH even when not interactive.
-      # This is inhibited by a guard in Debian's stock `bashrc` but some people remove it
-      # in order to get proper environment for noninteractive remote commands
-      # (SSH provides /etc/ssh/sshrc and ~/.ssh/rc for that but no-one seems to use them for some reason).
-      # This has caused an infinite `bashrc` execution loop for those people in the below nested Bash invocation (#2367).
-      # --norc negates this behavior of such a customized Bash.
-      echo 'PATH="$(bash --norc -ec '\''IFS=:; paths=($PATH); '
-      echo 'for i in ${!paths[@]}; do '
-      echo 'if [[ ${paths[i]} == "'\'\'"${PYENV_ROOT}/shims"\'\''" ]]; then unset '\'\\\'\''paths[i]'\'\\\'\''; '
-      echo 'fi; done; '
-      echo 'echo "${paths[*]}"'\'')"'
-      echo 'export PATH="'"${PYENV_ROOT}"'/shims:${PATH}"'
-      ;;
-  esac
+  # if no_push_path is set, guard the PATH manipulation with a check on whether
+  # the shim is already in the PATH.
+  if [ -n "$no_push_path" ]; then
+    case "$shell" in
+      fish )
+          echo 'if not contains -- "'"${PYENV_ROOT}/shims"'" $PATH'
+          print_path_prepend_shims
+          echo 'end'
+          ;;
+      * )
+          echo 'if [[ ":$PATH:" != *'\':"${PYENV_ROOT}"/shims:\''* ]]; then'
+          print_path_prepend_shims
+          echo 'fi'
+          ;;
+    esac
+  else
+    case "$shell" in
+      fish )
+        echo 'while set pyenv_index (contains -i -- "'"${PYENV_ROOT}/shims"'" $PATH)'
+        echo 'set -eg PATH[$pyenv_index]; end; set -e pyenv_index'
+        print_path_prepend_shims
+        ;;
+      * )
+        # Some distros (notably Debian-based) set Bash's SSH_SOURCE_BASHRC compilation option
+        # that makes it source `bashrc` under SSH even when not interactive.
+        # This is inhibited by a guard in Debian's stock `bashrc` but some people remove it
+        # in order to get proper environment for noninteractive remote commands
+        # (SSH provides /etc/ssh/sshrc and ~/.ssh/rc for that but no-one seems to use them for some reason).
+        # This has caused an infinite `bashrc` execution loop for those people in the below nested Bash invocation (#2367).
+        # --norc negates this behavior of such a customized Bash.
+        echo 'PATH="$(bash --norc -ec '\''IFS=:; paths=($PATH); '
+        echo 'for i in ${!paths[@]}; do '
+        echo 'if [[ ${paths[i]} == "'\'\'"${PYENV_ROOT}/shims"\'\''" ]]; then unset '\'\\\'\''paths[i]'\'\\\'\''; '
+        echo 'fi; done; '
+        echo 'echo "${paths[*]}"'\'')"'
+        print_path_prepend_shims
+        ;;
+    esac
+  fi
+}
+
+function print_path_prepend_shims() {
+    case "$shell" in
+      fish )
+          echo 'set -gx PATH '\'"${PYENV_ROOT}/shims"\'' $PATH'
+          ;;
+      * )
+          echo 'export PATH="'"${PYENV_ROOT}"'/shims:${PATH}"'
+          ;;
+    esac
 }
 
 function print_env() {

libexec/pyenv-latest

@@ -35,6 +35,12 @@ IFS=$'\n'
     else
         DEFINITION_CANDIDATES=( $(python-build --definitions ) )
     fi
+    
+    if printf '%s\n' "${DEFINITION_CANDIDATES[@]}" | grep -qxFe "$prefix"; then
+        echo "$prefix"
+        exit $exitcode;
+    fi
+    
     # https://stackoverflow.com/questions/11856054/is-there-an-easy-way-to-pass-a-raw-string-to-grep/63483807#63483807 
     prefix_re="$(sed 's/[^\^]/[&]/g;s/[\^]/\\&/g' <<< "$prefix")"
     # FIXME: more reliable and readable would probably be to loop over them and transform in pure Bash

plugins/python-build/bin/python-build

@@ -360,12 +360,38 @@ http_head_aria2c() {
 }
 
 http_get_aria2c() {
-  local out="${2:-$(mktemp "out.XXXXXX")}"
-  if aria2c --allow-overwrite=true --no-conf=true -o "${out}" ${ARIA2_OPTS} "$1" >&4; then
+  # aria2c always treats -o argument as a relative path
+  local out dir_out;
+  if [[ -n "$2" ]]; then
+    out="$(basename $2)";
+    dir_out="$(dirname $2)";
+  else
+    out="$(mktemp "out.XXXXXX")";
+    dir_out="$TMPDIR";
+  fi
+
+  # In Ubuntu, aria2c is only available as a snap. Snaps cannot read or write /tmp
+  # (files cannot be found, any write result is silently discarded).
+  local aria2c_is_snap;
+  if [[ $(command -v aria2c) == "/snap/"* ]]; then aria2c_is_snap=1; fi
+
+  if [[ -n $aria2c_is_snap ]]; then
+    local real_dir_out="$dir_out"
+    # presumably, snaps can always write to under $HOME
+    dir_out="$HOME"
+  fi
+
+  if aria2c --allow-overwrite=true --no-conf=true -d "${dir_out}" -o "${out}" ${ARIA2_OPTS} "$1" >&4; then
     [ -n "$2" ] || cat "${out}"
   else
     false
   fi
+  ret=$?
+
+  if [[ -n "$2" && -n $aria2c_is_snap ]]; then
+      mv "$dir_out/$out" "$real_dir_out/$out"
+  fi
+  return "$ret"
 }
 
 http_head_curl() {
@@ -1564,6 +1590,8 @@ use_homebrew_zlib() {
 }
 
 use_xcode_sdk_zlib() {
+  # If a custom compiler is used, including XCode SDK will likely break it
+  [[ "${CC:-clang}" != "clang" || "$(command -v clang 2>/dev/null || true)" != "/usr/bin/clang" ]] && return 1
   local xc_sdk_path="$(xcrun --show-sdk-path 2>/dev/null || true)"
   if [ -d "$xc_sdk_path" ]; then
     echo "python-build: use zlib from xcode sdk"

plugins/python-build/share/python-build/3.12.0a1

@@ -1,9 +0,0 @@
-prefer_openssl11
-export PYTHON_BUILD_CONFIGURE_WITH_OPENSSL=1
-install_package "openssl-1.1.1q" "https://www.openssl.org/source/openssl-1.1.1q.tar.gz#d7939ce614029cdff0b6c20f0e2e5703158a489a72b2507b8bd51bf8c8fd10ca" mac_openssl --if has_broken_mac_openssl
-install_package "readline-8.2" "https://ftpmirror.gnu.org/readline/readline-8.2.tar.gz#3feb7171f16a84ee82ca18a36d7b9be109a52c04f492a053331d7d1095007c35" mac_readline --if has_broken_mac_readline
-if has_tar_xz_support; then
-    install_package "Python-3.12.0a1" "https://www.python.org/ftp/python/3.12.0/Python-3.12.0a1.tar.xz#7be2bd9b1fc9f64b334660581bb645f0eae0b344c80130f1eb22983a1c292f43" standard verify_py312 copy_python_gdb ensurepip
-else
-    install_package "Python-3.12.0a1" "https://www.python.org/ftp/python/3.12.0/Python-3.12.0a1.tgz#db4dd2315715e11250175f5dc06fa9d32d4a9fed4db7b6774d4be72d7b94b7e3" standard verify_py312 copy_python_gdb ensurepip
-fi

plugins/python-build/share/python-build/3.12.0a2

@@ -0,0 +1,9 @@
+prefer_openssl11
+export PYTHON_BUILD_CONFIGURE_WITH_OPENSSL=1
+install_package "openssl-1.1.1s" "https://www.openssl.org/source/openssl-1.1.1s.tar.gz#c5ac01e760ee6ff0dab61d6b2bbd30146724d063eb322180c6f18a6f74e4b6aa" mac_openssl --if has_broken_mac_openssl
+install_package "readline-8.2" "https://ftpmirror.gnu.org/readline/readline-8.2.tar.gz#3feb7171f16a84ee82ca18a36d7b9be109a52c04f492a053331d7d1095007c35" mac_readline --if has_broken_mac_readline
+if has_tar_xz_support; then
+    install_package "Python-3.12.0a2" "https://www.python.org/ftp/python/3.12.0/Python-3.12.0a2.tar.xz#1eafc1384e532cac6432632a77350ef504a114c4235c1f6f2a85f817f5b1926a" standard verify_py312 copy_python_gdb ensurepip
+else
+    install_package "Python-3.12.0a2" "https://www.python.org/ftp/python/3.12.0/Python-3.12.0a2.tgz#81fa3468cada25f5ac8868230a847999495464f8ab67df1df3e8e8e280df0b2b" standard verify_py312 copy_python_gdb ensurepip
+fi

plugins/python-build/share/python-build/patches/3.8.15/openssl-1.1.1q/openssl_1.1.1q_fix_c_include.patch

@@ -0,0 +1,12 @@
+diff --git a/test/v3ext.c b/test/v3ext.c
+index 7a240cd706..6cec6f1a9b 100644
+--- a/test/v3ext.c
++++ b/test/v3ext.c
+@@ -15,6 +15,7 @@
+ #include <openssl/err.h>
+ #include "internal/nelem.h"
+ 
++#include <string.h>
+ #include "testutil.h"
+ 
+ static const char *infile;

plugins/python-build/share/python-build/patches/3.9.15/openssl-1.1.1q/openssl_1.1.1q_fix_c_include.patch

@@ -0,0 +1,12 @@
+diff --git a/test/v3ext.c b/test/v3ext.c
+index 7a240cd706..6cec6f1a9b 100644
+--- a/test/v3ext.c
++++ b/test/v3ext.c
+@@ -15,6 +15,7 @@
+ #include <openssl/err.h>
+ #include "internal/nelem.h"
+ 
++#include <string.h>
+ #include "testutil.h"
+ 
+ static const char *infile;

plugins/python-build/test/fetch.bats

@@ -21,7 +21,7 @@ setup() {
 @test "using aria2c if available" {
   export PYTHON_BUILD_ARIA2_OPTS=
   export -n PYTHON_BUILD_HTTP_CLIENT
-  stub aria2c "--allow-overwrite=true --no-conf=true -o * http://example.com/* : cp $FIXTURE_ROOT/\${5##*/} \$4"
+  stub aria2c "--allow-overwrite=true --no-conf=true -d * -o * http://example.com/* : cp $FIXTURE_ROOT/\${7##*/} \$6"
 
   install_fixture definitions/without-checksum
   assert_success

pyenv.d/rehash/source.d/default.list

@@ -2,5 +2,6 @@
 activate
 activate.csh
 activate.fish
+activate.nu
 # gettext (#688)
 gettext.sh

test/init.bats

@@ -98,7 +98,6 @@ echo "\$PATH"
   command -v fish >/dev/null || skip "-- fish not installed"
   OLDPATH="$PATH"
   export PATH="${BATS_TEST_DIRNAME}/nonexistent:${PYENV_ROOT}/shims:$PATH"
-  # fish 2 (Ubuntu Bionic) adds spurious messages when setting PATH, messing up the output
   run fish <<!
 set -x PATH "$PATH"
 pyenv init - | source
@@ -108,6 +107,50 @@ echo "\$PATH"
   assert_output "${PYENV_ROOT}/shims:${BATS_TEST_DIRNAME}/nonexistent:${OLDPATH//${PYENV_ROOT}\/shims:/}"
 }
 
+@test "adds shims to PATH with --no-push-path if they're not on PATH" {
+  export PATH="${BATS_TEST_DIRNAME}/../libexec:/usr/bin:/bin:/usr/local/bin"
+  run bash -e <<!
+eval "\$(pyenv-init - --no-push-path)"
+echo "\$PATH"
+!
+  assert_success
+  assert_output "${PYENV_ROOT}/shims:${PATH}"
+}
+
+@test "adds shims to PATH with --no-push-path if they're not on PATH (fish)" {
+  command -v fish >/dev/null || skip "-- fish not installed"
+  export PATH="${BATS_TEST_DIRNAME}/../libexec:/usr/bin:/bin:/usr/local/bin"
+  run fish <<!
+set -x PATH "$PATH"
+pyenv-init - --no-push-path| source
+echo "\$PATH"
+!
+  assert_success
+  assert_output "${PYENV_ROOT}/shims:${PATH}"
+}
+
+@test "doesn't change PATH with --no-push-path if shims are already on PATH" {
+  export PATH="${BATS_TEST_DIRNAME}/../libexec:${PYENV_ROOT}/shims:/usr/bin:/bin:/usr/local/bin"
+  run bash -e <<!
+eval "\$(pyenv-init - --no-push-path)"
+echo "\$PATH"
+!
+  assert_success
+  assert_output "${PATH}"
+}
+
+@test "doesn't change PATH with --no-push-path if shims are already on PATH (fish)" {
+  command -v fish >/dev/null || skip "-- fish not installed"
+  export PATH="${BATS_TEST_DIRNAME}/../libexec:/usr/bin:${PYENV_ROOT}/shims:/bin:/usr/local/bin"
+  run fish <<!
+set -x PATH "$PATH"
+pyenv-init - --no-push-path| source
+echo "\$PATH"
+!
+  assert_success
+  assert_output "${PATH}"
+}
+
 @test "outputs sh-compatible syntax" {
   run pyenv-init - bash
   assert_success

test/latest.bats

@@ -64,6 +64,21 @@ pyenv: no known versions match the prefix \`3.8'
 !
 }
 
+@test "complete name resolves to itself" {
+  create_executable pyenv-versions <<!
+#!$BASH
+echo foo
+echo foo.bar
+!
+
+run pyenv-latest foo
+assert_success
+assert_output <<!
+foo
+!
+
+}
+
 @test "sort CPython" {
   create_executable pyenv-versions <<!
 #!$BASH