Since Emacs 27 the package cl is deprecated, the replacement is
cl-lib, which is available since Emacs 24.3.
This patch replaces cl by cl-lib and drops support for Emacs versions
less than 24.3. Dropping older Emacsen is required, because cl-lib is
a builtin starting from version 24.3 and doesn't need an extra package
from ELPA.
Testcases for past issues still contain cl. Most of them seem to be
broken and need further investigation.
This patch is tested with test/run-ert.sh, which outputs:
Ran 10 tests, 10 results as expected, 0 unexpected (2021-01-30 13:24:54+0100, 0.672122 sec)
1 expected failures
and manually by daily usage for a month now.
* el-get-methods.el (el-get-insecure-check): Also consider URLs
satisfying `file-name-absolute-p' to be secure. `package-archives' uses
absolute file names *without* file:// prefix, so we have allow this too.
* methods/el-get-elpa.el (el-get-elpa-package-id):
(el-get-elpa-package-archive-base): New compat functions.
* methods/el-get-elpa.el (el-get-elpa-install): Call
`el-get-insecure-check' after ensuring `package-archive-contents' is
initialized.
Some methods, :elpa for instance, need some some special handling to
figure out the URL. In the mean time, don't throw assertion violations
if the user didn't ask to check for "insecure" packages anyway.
* el-get-methods.el (el-get-insecure-check): Move check of
`el-get-allow-insecure' to beginning, before the assertion. Change the
parameter names to lower case, as is customary in elisp.
URL starting with 'file:///' (hostname is empty) is secure because it
always points to a local file.
OTOH, 'file://example.com/' (with any hostname, including 'localhost'
and '127.0.0.1') is insecure as it may refer to the remote file and
deciding if some hostname is actually a local in given moment in time is
tricky and too error-prone.
...because not a package itself but a URL user trying to install it from
is actually insecure. Mention URL in the error message like
Attempting to install package ag from insecure URL user@ftp://example.com/ without `el-get-allow-insecure
for easier troubleshooting.
If the package recipe has a :checksum property no more work is needed:
either the checksum matches in which case we have a trusted version of
the package, or it fails to match (or doesn't have a :compute-checksum
method) so we get an error raised on el-get-post-install.
* el-get-methods.el (el-get-insecure-check): don't raise error if
package recipe has :checksum property.
In most cases, we assume any connection is insecure unless the URL
starts with "https://", "$USERNAME@", or "ssh". There are a few
exceptions: I'm assuming all Emacswiki packages are insecure, and I
don't think we can know whether packages installed via Google Go are
secure or not.
Several go related tools can be used within emacs, such as:
gocode, godef, goimports, golint, goflymake, etc.
The el-get-go method lets the 'go get' command take care of
downloading and building such tools. The main advantage is letting
go get take care of resolving dependecies and building the binary,
rather than wedging into the :build property.
This includes teaching methods that they now work with a symbolp PACKAGE,
some more cleaning up, and some load-path adjustments now that a part of the
code is in a subdirectory (methods).
Also include some of the tests used to convince oneself that the refactoring
didn't break any and all use cases for el-get, with some rough documentation
about how to use them.
