The glob pattern we were using was too permissive and detecting
miniconda build scripts as miniforge build scripts when they shared the
same version. I have rewritten the pattern matching code to ensure we
only look at files starting with `miniforge` and `mambaforge`.

I was attempting to run the script to generate build files for new
versions, but it failed because version `23.1.0-4`[^1] contained a
malformed `.sha256` file.[^2] I looked at the miniforge repo's script
`releases.py`[^3] and copied the logic about which release artifacts
should be skipped when generating a list of downloads.

[^1]: https://github.com/conda-forge/miniforge/releases/tag/23.1.0-4
[^2]: https://github.com/conda-forge/miniforge/releases/download/23.1.0-4/Miniforge3-uninstaller-patch-Windows-x86_64.exe.sha256
[^3]: a15762906b/docs/releases.py (L35-L36)

This reverts commit 932dc464f5.

Co-authored-by: Edgar Ramírez Mondragón <16805946+edgarrmondragon@users.noreply.github.com>

Releases have been reuploaded upstream

Co-authored-by: Dan Dees <dand@appsmiths.com>

Co-authored-by: binbjz <bin.zhao@naxions.com>

Needed to link against libpython of the Pyenv-controlled installation

As per https://docs.python.org/3.11/whatsnew/3.11.html#notable-changes-in-3-11-5,
OpenSSL 3.0 support in CPython is finally official since 3.11.5.

Using the same name as graalpy causes a cache clash

grammar

This adds anaconda 2023.09 and miniconda 23.9.0.

The code for determining which Python version is bundled with which
version of Anaconda has not been updated in a while. I have added 3.10
and 3.11, both of which were used in bundles this year.

I also updated the URL for the source of this data, the Anaconda release
notes, because it has moved.

Headers have been moved to the 'tcl-tk' subdir
This was causing Tcl/Tk 8.5 from XCode SDK to be silently picked instead

XCode Command Line Tools 15.0 was recently released, and it contains a
broken version of ncurses 6.0. Some uses of Python's `curses` module
will segfault when compiled with it. The solution is to switch to using
the version of ncurses from Homebrew, which is currently 6.4. Support
for ncurses 6 was added to Python 3.7 and was backported to 3.6 and 2.7,
so this change should not break any recently supported Python versions.

Tested with Python 3.12, 3.11, and 2.7, and all tests in
the `test.test_curses` module pass without issue.

See https://github.com/python/cpython/issues/109617 and
https://github.com/python/cpython/issues/69906 for more information.

* Use the new Oracle GraalVM distribution to provide the best user experience,
  as it significantly faster than GraalVM CE and is free for development and production use:
  https://medium.com/graalvm/whats-new-in-graalvm-languages-161527df3d76

It seems that pyenv cannot install 2.7.18 on Mac M1 (Apple ARM).

openssl 1.0.2 does not have ARM support. M1 support was added in 1.1.1i according to
https://www.openssl.org/news/cl111.txt

All include directories should go into CPPFLAGS.
XCode SDK was being added to CFLAGS instead
which caused old Tcl/Tk in the SDK to override a newer one in Homebrew.

The old 3.1.1s URL returns a 404

The -s flag assures that nothing can be installed to user site-packages
but doesn't keep ensurepip from looking there for Pip.
If Pip is installed in the user site-packages directory, pip won't be installed
for the newly built python -- and its shim won't be created.
-I makes the build install Pip in any case.
The user site-packages installation will override it --
but we'll have the shim at least.