Drop support for GNU ELPA

It's unnecessary since we have EmacsMirror, and dealing with it is
thoroughly unpleasant. If somebody *else* wants to maintain it, I'd
welcome a pull request for that.

See radian-software#18.

README.md

@@ -76,8 +76,8 @@ for the [Emacs] hacker.
 
 ## Features
 
-* Install Emacs packages from [MELPA], [GNU ELPA][gnu-elpa],
-  [EmacsMirror], or manually specified sources.
+* Install Emacs packages from [MELPA], [EmacsMirror], or manually
+  specified sources.
 * Clone and manage packages as Git (or other) repositories, not as
   opaque tarballs.
 * Make changes to a package simply by editing its source code, no
@@ -116,7 +116,7 @@ for the [Emacs] hacker.
 * No support whatsoever for `package.el`.
 * Edit packages by editing their code, no extra steps required. Allow
   for manual version control operations.
-* Compatibility with MELPA, GNU ELPA, and EmacsMirror.
+* Compatibility with MELPA and EmacsMirror.
 * Trivial to quickly try out a package without permanently installing
   it.
 * Good for reproducing an issue with `emacs -Q`.
@@ -164,11 +164,12 @@ on [the init lifecycle][init-lifecycle].
 
 ### Install packages
 
-Out of the box, you can install any package from
-[MELPA], [GNU ELPA][gnu-elpa], or [EmacsMirror]. To install a package
-temporarily (until you restart Emacs), run `M-x straight-use-package`
-and select the package you want. To install a package permanently,
-place a call to `straight-use-package` in your init-file, like:
+Out of the box, you can install any package from [MELPA] or
+[EmacsMirror], which is to say any package in existence. To install a
+package temporarily (until you restart Emacs), run `M-x
+straight-use-package` and select the package you want. To install a
+package permanently, place a call to `straight-use-package` in your
+init-file, like:
 
     (straight-use-package 'el-patch)
 
@@ -943,14 +944,13 @@ And here is a brief list of the main reasons you might not want to use
 
 #### Advantages of `straight.el`
 
-* `straight.el` has out-of-the-box compatibility with GNU ELPA and
-  EmacsMirror, while Quelpa only has support for MELPA. To use GNU
-  ELPA, you must drop down to `package.el`. [EmacsMirror] is not
-  supported by default, although it is easy to specify an EmacsMirror
-  repository in a recipe. While Quelpa allows you to specify custom
-  recipe folders, it does not have support for cloning these folders
-  automatically from version control, nor for generating the recipes
-  in any way other than copying them literally from files.
+* `straight.el` has out-of-the-box compatibility with MELPA and
+  EmacsMirror, while Quelpa only has support for MELPA. [EmacsMirror]
+  is not supported by default, although it is easy to specify an
+  EmacsMirror repository in a recipe. While Quelpa allows you to
+  specify custom recipe folders, it does not have support for cloning
+  these folders automatically from version control, nor for generating
+  the recipes in any way other than copying them literally from files.
   `straight.el` allows you full flexibility in this regard.
 * `straight.el` has integrated support for selecting particular Git
   revisions of packages. This process is more manual in Quelpa, as it
@@ -1059,8 +1059,8 @@ offer corrections for this section.
   while Cask only supports `package.el`-compliant repositories.
   However, it is easy to specify an EmacsMirror repository in a
   recipe. Cask does not support custom package sources. `straight.el`
-  supports GNU ELPA, MELPA, and EmacsMirror, and allows you to add any
-  other sources you would like.
+  supports MELPA and EmacsMirror, and allows you to add any other
+  sources you would like.
 * `straight.el` has integrated support for selecting particular Git
   revisions of packages. This process is more manual in Cask, as it
   requires placing the commit hash into the recipe, which disables
@@ -1222,13 +1222,12 @@ offer corrections for this section.
 
 #### Advantages of `straight.el`
 
-* `straight.el` supports GNU ELPA, MELPA, EmacsMirror, and custom
-  recipe sources. Borg only supports EmacsMirror and custom recipe
-  sources. However, as the EmacsMirror is a complete superset of both
-  GNU ELPA and MELPA, this does not mean you have access to more
-  packages: it just means you benefit from the recipe maintenance
-  efforts of the MELPA team and the EmacsMirror team, rather than only
-  the latter.
+* `straight.el` supports MELPA, EmacsMirror, and custom recipe
+  sources. Borg only supports EmacsMirror and custom recipe sources.
+  However, as the EmacsMirror is a complete superset of MELPA, this
+  does not mean you have access to more packages: it just means you
+  benefit from the recipe maintenance efforts of the MELPA team and
+  the EmacsMirror team, rather than only the latter.
 * Borg, even when combined with related tools, do not allow for the
   kind of massive interactive repository management provided by
   `straight.el`.
@@ -1658,12 +1657,12 @@ You can customize the following user options:
 ### Recipe lookup
 
 If you only provide a symbol (package name) to `straight-use-package`,
-then the recipe is looked up automatically. By default,
-[MELPA], [GNU ELPA][gnu-elpa], and [EmacsMirror] are all searched for
-recipes, in that order. This means that one or more of them may need
-to be cloned. Recipe repositories are actually just the same as
-ordinary packages, except that their recipes specify `:no-build`, so
-they are not symlinked or added to the `load-path` or anything.
+then the recipe is looked up automatically. By default, [MELPA] and
+[EmacsMirror] are searched for recipes, in that order. This means that
+one or more of them may need to be cloned. Recipe repositories are
+actually just the same as ordinary packages, except that their recipes
+specify `:no-build`, so they are not symlinked or added to the
+`load-path` or anything.
 
 Note that dependencies always use the default recipes, since the only
 information `straight.el` gets about a package's dependencies are
@@ -1714,7 +1713,7 @@ can control which recipe repositories are searched, and in what order
 of precedence, by customizing `straight-recipe-repositories`. The
 default value is:
 
-    (melpa gnu-elpa emacsmirror)
+    (melpa emacsmirror)
 
 To define a new recipe repository called `NAME`, you should do the
 following things:
@@ -2174,7 +2173,6 @@ since `font-lock-mode` computes syntax highlighting lazily.
 [emacsmirror]: https://emacsmirror.net/
 [emacswiki]: https://www.emacswiki.org/
 [epkg]: https://github.com/emacscollective/epkg
-[gnu-elpa]: https://elpa.gnu.org/
 [issues]: https://github.com/raxod502/straight.el/issues
 [magit]: https://magit.vc/
 [melpa-recipe-format]: https://github.com/melpa/melpa#recipe-format

bootstrap.el

@@ -83,11 +83,6 @@
                               :repo "melpa/melpa"
                               :no-build t))
 
-(straight-use-recipes `(gnu-elpa :type git
-                                 :repo ,straight-recipes-gnu-elpa-url
-                                 :local-repo "elpa"
-                                 :no-build t))
-
 (straight-use-recipes '(emacsmirror :type git :host github
                                     :repo "emacsmirror/epkgs"
                                     :nonrecursive t

install.el

@@ -154,8 +154,7 @@
                          straight-vc-git-primary-remote
                          straight-vc-git-upstream-remote
                          straight-vc-git-default-protocol
-                         straight-vc-git-force-protocol
-                         straight-recipes-gnu-elpa-url)))
+                         straight-vc-git-force-protocol)))
        (current-buffer))
       (goto-char (point-max))
       (print

straight.el

@@ -13,8 +13,8 @@
 ;; clones packages into your ~/.emacs.d and handles byte-compilation,
 ;; autoload generation, and load path management. Dependency
 ;; management, powerful tools for managing your packages in bulk, and
-;; out-of-the-box compatibility with MELPA, GNU ELPA, and EmacsMirror
-;; are also included.
+;; out-of-the-box compatibility with MELPA and EmacsMirror are also
+;; included.
 
 ;; straight.el improves on other package managers in several ways.
 ;; Most importantly, it offers first-class support for easily
@@ -1443,32 +1443,6 @@ return nil."
   "Return a list of recipes available in MELPA, as a list of strings."
   (directory-files "recipes" nil "^[^.]" 'nosort))
 
-;;;;;; GNU ELPA
-
-(defcustom straight-recipes-gnu-elpa-url
-  "https://git.savannah.gnu.org/git/emacs/elpa.git"
-  "URL of the Git repository for the GNU ELPA package repository."
-  :type 'string
-  :group 'straight)
-
-(defun straight-recipes-gnu-elpa-retrieve (package)
-  "Look up a PACKAGE recipe in GNU ELPA.
-PACKAGE should be a symbol. If the package is maintained in GNU
-ELPA, a MELPA-style recipe is returned. Otherwise nil is
-returned."
-  (when (file-exists-p (concat "packages/" (symbol-name package)))
-    ;; All the packages in GNU ELPA are just subdirectories of the
-    ;; same repository.
-    `(,package :type git
-               :repo ,straight-recipes-gnu-elpa-url
-               :files (,(format "packages/%s/*.el"
-                                (symbol-name package)))
-               :local-repo "elpa")))
-
-(defun straight-recipes-gnu-elpa-list ()
-  "Return a list of recipes available in GNU ELPA, as a list of strings."
-  (directory-files "packages" nil "^[^.]" 'nosort))
-
 ;;;;;; EmacsMirror
 
 (defun straight-recipes-emacsmirror-retrieve (package)
@@ -1637,11 +1611,11 @@ for dependency resolution."
               ;;
               ;; Instead, this code makes it so that if a recipe has
               ;; been automatically retrieved from a recipe repository
-              ;; (for example, MELPA, GNU ELPA, or Emacsmirror), and
-              ;; the `:local-repo' specified in that recipe has
-              ;; already been used for another package, then the
-              ;; configuration for that repository will silently be
-              ;; copied over, and everything should "just work".
+              ;; (for example, MELPA or Emacsmirror), and the
+              ;; `:local-repo' specified in that recipe has already
+              ;; been used for another package, then the configuration
+              ;; for that repository will silently be copied over, and
+              ;; everything should "just work".
               ;;
               ;; Note that this weird edge case is totally unrelated
               ;; to the weird edge cases discussed earlier (in the