`doom sync --profile` broken due to `noninteractive`

[hpfr]

I confirm that...

• I have searched the issue tracker, documentation, FAQ, Discourse, and Google, in case this issue has already been reported/resolved.
• I have read "How to Debug Issues", and will use it to provide as much information about this issue as possible.
• The issue can be reproduced on the latest available commit of Doom.
• The issue can be reproduced on a stable release of Emacs, such as 27, 28, or 29. (Unstable versions end in .50, .60, or .9x)

Expected behavior

doom sync --profile FOO should work per:

doomemacs/profiles/README.org

Line 38 in 3983fba

- Use ~bin/doom~ on the profile you want: ~$ doom sync --profile FOO~

Current behavior

0 2023-09-23 11:47:01 $ doom profiles sync
Loading /nix/store/qkasnjq86si8vspaxpz0rm9s96i21hdz-emacs-pgtk-29.1/share/emacs/site-lisp/site-start (native compiled elisp)...
  > Synchronizing 2 known profiles...
    - Added sandbox
    ✓ Regenerated profile loader: ~/.config/emacs/profiles/load.el
✓ Finished in 0.10372s


0 2023-09-23 11:47:06 $ doom sync --profile sandbox
Loading /nix/store/qkasnjq86si8vspaxpz0rm9s96i21hdz-emacs-pgtk-29.1/share/emacs/site-lisp/site-start (native compiled elisp)...
Loading /nix/store/qkasnjq86si8vspaxpz0rm9s96i21hdz-emacs-pgtk-29.1/share/emacs/site-lisp/site-start (native compiled elisp)...
> Synchronizing "sandboxEMACSDIR=/home/lh/.config/emacs/" profile...
  > Installing packages...
    - No packages need to be installed
  > (Re)building packages...
    - No packages need rebuilding
  > Purging orphaned packages (for the emperor)...
    - Skipping builds
    - Skipping elpa packages
    - Skipping repos
    - Skipping regrafting
    - Skipping native bytecode
  > (Re)building profile in /home/lh/.local/share/doom/sandboxEMACSDIR=/home/lh/.config/emacs/@/...
    > Deleting old init files...
    > Generating 4 init files...
    > Byte-compiling ~/.local/share/doom/sandboxEMACSDIR=/home/lh/.config/emacs/@/0init.29.el...
    ✓ Built init.29.elc
  - Restart Emacs or use 'M-x doom/reload' for changes to take effect
✓ Finished in 2.46945s
0 2023-09-23 11:47:19 $ ls ~/.local/share/doom/
'sandboxEMACSDIR='

I think this is because command-line-args is unset here, so profile is nil:

doomemacs/early-init.el

Lines 54 to 61 in 3983fba

	(let* (;; FIX: Unset `command-line-args' in noninteractive sessions, to
	;; ensure upstream switches aren't misinterpreted.
	(command-line-args (unless noninteractive command-line-args))
	;; I avoid using `command-switch-alist' to process --profile (and
	;; --init-directory) because it is processed too late to change
	;; `user-emacs-directory' in time.
	(profile (or (cadr (member "--profile" command-line-args))
	(getenv-internal "DOOMPROFILE"))))

When I added (message "profile is %s" profile) after the let and (message "set DOOMPROFILE to %s" profile) after the subsequent (setenv "DOOMPROFILE" profile), I got some strange output:

0 2023-09-23 13:03:22 $ doom sync --profile sandbox
profile is nil
Loading /nix/store/qkasnjq86si8vspaxpz0rm9s96i21hdz-emacs-pgtk-29.1/share/emacs/site-lisp/site-start (native compiled elisp)...
profile is sandboxEMACSDIR=/home/lh/.config/emacs/
set DOOMPROFILE to sandboxEMACSDIR=/home/lh/.config/emacs/
Loading /nix/store/qkasnjq86si8vspaxpz0rm9s96i21hdz-emacs-pgtk-29.1/share/emacs/site-lisp/site-start (native compiled elisp)...
> Synchronizing "sandboxEMACSDIR=/home/lh/.config/emacs/" profile...

It’s like this file is loaded twice with different contexts? I don’t know. I considered attempting to fix this, but the code is pretty hairy, and I don’t have an ergonomic way to test Emacs 28 currently. The DOOMPROFILE environment variable works fine as a workaround. In fact, I’m guessing you didn’t catch --profile was broken because you use the environment variable. Maybe you could just drop one of the two interfaces?

Then again, I’m surprised no one else ran into this, so maybe something weirder is happening…

Steps to reproduce

see previous

System Information

https://pastebin.com/mmJ3391G

[hlissner]

Good catch. This should be fixed in fe18640. Let me know if that isn't the case!