According to Miniforge README, they are only meant for interactive installation

They unexpectedly made a prerelease 3.14.5rc1

exit code 1 is used as a signal that no new version is found -- so have to use a different exit code for unhandled exceptions

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

[no ci]

fix KeyError: out_dir

Looks like a leftover from older logic, before
we `git mv`'d thunks on prerelease upgrade

* For files retrieved through the GNU mirror load balancer, specify the load balancer URL
* Explicitly `git mv` files on prerelease upgrade in case Git doesn't detect it
* Add a trailing newline to a thunk

* .gitignore local venv
* Add alt GNU mirror support with <table>
* Fix UnboundLocalError when no micro 0 releases
* Cutoff for existing vetsions as well
* add missing dependency more_itertools
* workaround fake_useragent 2.0.0 falsely declaring 3.8 compatibility

Required for installation since this version

Latest version are okay.
Freezing them causes Dependabot alerts
about vulnerabilities in old versions

[no ci]

Adds latest miniforge releases 25.9.1-0, 25.11.0-1.

Skips 25.11.0-0 due to a regression reported in the release notes of
miniforge3-25.11.0-1.

Ref: https://github.com/conda-forge/miniforge/releases/tag/25.11.0-1

At least under Python 3.14, this quickly fails without lxml[html_clean]
installed explicitly.

miniforge-25.3.0-0 is marked as prerelease, there's no Linux version. Probably recalled.

* report more progress
* don't download SHA files for unsupported architectures

* future-proof PyVersion
* fix handling "-latest"
* Update default versions
* change -v argument to bool

We always detect missing build scripts for `4.13.0-0` because the
release[^1] doesn't have any mambaforge artifacts. Given that we've
already created the build files, we don't need to check the release
again.

[^1]: https://github.com/conda-forge/miniforge/releases/tag/4.13.0-0

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)

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.

Anaconda and miniconda have changed their version string format again,
so the parsing needs to be done differently. `add_miniconda.py` can now
parse all existing definition files properly.

This makes it easier to fix file names that cannot be parsed using the
current logic.

This takes inspiration from the similar script for miniconda, but it
simplifies in a couple of ways:

1. Use the GitHub Releases API instead of scraping HTML.
2. Don't perform a diff, simply add the latest release.

Lots of intermediate miniconda releases have been skipped in the past,
and it doesn't seem particularly valuable to backfill those.

Required to prevent a crash when no verbosity given.

README, better docs + logging

Scrapes available miniconda builds from anaconda repo