Eventually, I want to autoload some of this stuff, so that users in
interactive sessions can safely load it without side effects (useful
when writing their own CLIs or editing Doom's source).
sxhash doesn't guarantee hashes are consistent across Emacs sessions, so
use md5 instead. Also simplifies what's getting hashed;
`system-configuration` is a sufficient substitute for both `system-type`
and what I wanted to glean from changes in
`system-configuration-features`.
Amend: 80e9263b85Close: #8030
Ref: #8024
Co-authored-by: yaaama <yaaama@users.noreply.github.com>
Turns out native-comp doesn't respect
`native-comp-jit-compilation-deny-list` if called explicitly (instead of
from deferred compilation).
Fix: #5592Fix: #6283Fix: #3655
I intend to eventually replace projectile with project.el, so these
doom-projectile-* variables need to be generalized, starting with the
fd/ripgrep executable paths.
ALong with that, this refactors Doom's projectile-generic-command to
lean more on built-in fd support in projectile, where possible (fewer
wheels reinvented).
Ref: doomemacs/core#1
Allow ahead-of-time native-compilation during CLI operations that
install or update packages. This will not retroactively native-compile
already-installed packages, you'll need to use --rebuild to do so.
(This is a stop-gap solution until the v3.0 release)
Fix: #6811
When running `doom sync --rebuild` after emacs upgrade the user is
prompted with "Installed packages must be rebuilt. Do so now?", even
though doom was explicitly instructed to rebuild. This PR removes this
prompt when the `--rebuild` option is provided
Before this, text that extended past the new line's length would
persist, causing garbled output like this:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Cloning org-appear...r emacsmirror-mirror...
- No packages need attention
Which might lead you to believe org-appear is being cloned from
emacsmirror-mirror, but the full output is actually:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Updating recipes for melpa...
> Updating recipes for nongnu-elpa...
> Updating recipes for gnu-elpa-mirror...
> Updating recipes for el-get...
> Updating recipes for emacsmirror-mirror...
> Cloning org-appear...
- No packages need attention
The -!/--force flags suppress straight's 'how to proceed' prompts, but
not the secondary ones like 'Really delete remote "origin"?'. This fixes
that.
Fix: #7906
If the package is local, the local-repo has absolute local file path,
and straight-modified-dir will return as it is, which always exists.
Fix it by passing package only to straight-modified-dir.
Doom makes multiple attempts to re-clone repos if they failed the first
time, however, if a user provides a :local-repo and that location isn't
a git repo, Doom assumes this it is the result of a failed clone, and so
deletes it to "try" again (which will fail). This can result in lost
work.
This prevents this from happening to packages/repos outside of
$DOOMLOCALDIR (all packages under $DOOMLOCALDIR must be git repos).
Fix: #7785
Amend: 3643c4dadd
Amend: 1fa8d3a4b9
directory-empty-p was introduced in 28.1, but Doom still supports 27.1,
so 27.x users would see this error when running any bin/doom command
that clones packages.
Fix: #7779
Amend: 1fa8d3a4b9
It seems the temporary branch that 'doom upgrade' creates is sometimes
left over after a 'doom upgrade', preventing the next 'git fetch' from
completing.
Ref: #7771
Caused by a regression originally introduced in b6b755d, but incorrectly
fixed in 89c56a3. Don't code while sleep deprived, kids.
Amend: 89c56a3393
Amend: b6b755dea4
12a765c introduced suppression of package-rebuilding prompts on 'doom
upgrade', but inadvertently reversed the check. This fixes that (and
refactors the if/or tree into a `cond`).
Amend: 12a765c509
Prior to this, -B would suppress the prompt for package rebuilding if
your Emacs version or hostname changed. Now, it fully inhibits
rebuilding in either case.
Fix: #7760
Ref: cff091982e
'doom purge' is now deprecated.
Also changes 'doom sync's -p option to --gc. Since GCing causes the loss
of historical data, I'd rather it be a long option to make it a little
harder to do accidentally.
This changes 'doom sync' to be smarter about responding to changed
package recipes/pins, changes in Emacs version, or instances where the user
has copied a config to a new system.
In all these cases, the user would formerly have to know about a
specific combination of 'doom sync -u' and 'doom build' to ensure Doom
is in a good state. With this change, 'doom sync' handles all these
cases.
Also, 'doom build' is now deprecated (and 'doom sync' now has a
--rebuild option to mimic its old behavior).
Also also, sometimes, a package may silently fail when cloned (which
used to result in an empty repo). Now, if this is detected, cloning will
be re-attempted up to 3 times before aborting with much more visible
error.
Note: these are stopgap solutions, until v3 is finished.
Something often reported are file-missing errors when a package that
should be present isn't. This can easily happen if, say, during a 'doom
sync' or 'doom upgrade' a package fails to clone correctly and the user
misses the errors, then tries to carry on as normal. What's worse is
that Straight leaves behind an empty directory, which it treats as a
sign that the package has been cloned correctly, so it doesn't raise any
fuss over them.
With this change, 'doom sync' (and 'doom upgrade') will now try again,
if the clone process fails the first time (up to 3 times) before
aborting the whole process altogether, which should be loud enough for
users not to miss. Note that these failures at 99.99% because of
network (or upstream downtime) issues.
For now, this does leave Doom in an incomplete state (until you try
again when the connection issue is resolved), but a rollback step will
be added in v3 to prevent this, as well as better error messages (as
well as @doomelpa mirror for packages on less reliable hosts, like
codeberg, savannah, etc).
BREAKING CHANGE: This removes the 'doom compile' and 'doom clean'
commands, and offers no immediate replacement for them (and no plan to
include one). In the future, byte-compilation of Doom's internals will
be baked into 'doom sync', but until then, Doom is not optimized to take
advantage of byte-compilation, and forcing it provides no benefit.
