error: string '.doom.d' doesn't represent an absolute path

       at /nix/store/bb4m4r0yaxw884sg3ljpxsijnpdcwp1a-source/modules/home-manager.nix:23:83:

           22|       '';
           23|       apply = path: if lib.isStorePath path then path else builtins.path { inherit path; };
             |                                                                                   ^
           24|     };

with quotes

building the system configuration...                                                                                         
error: builder for '/nix/store/jqvajznhf1l71xki56jjk8hcjh101fwa-emacs-straight-packages.json.drv' failed with exit code 255; 
       last 10 log lines:                                                                                                    
       >       (let ((temp-file (doom-path doom-user-dir filename)) (temp-buffer (gen...                                     
       >       (if (let ((p (let ((file filename)) (and (stringp file) (let ((default...                                     
       >       (let* ((template file) (filename (if template (car-safe (prog1 templat...                                     
       >       ((closure ((yes\?) (context . #s(doom-cli-context (25499 20286 853833 ...
       >       (mapc (closure ((yes\?) (context . #s(doom-cli-context (25499 20286 85...                                     
       >       (let ((doom-print-indent (+ (if t doom-print-indent-increment 0) doom-...                                     
       >       (if (eq config\? :no) (doom-print (doom-print--format (doom-print--cla...
       >       (let ((default-directory doom-emacs-dir) (yes\? (progn (or (progn (and...
       >     ! Wrote extended backtrace to /build/tmp.WnTRvLsVAJ/local/logs/cli.doom.221215164550.7.error
       > Opening output file: No such file or directory, /nix/store/gkx1higpi40h8nywz81kxczhw91080xs-.doom.d/init.el
       For full logs, run 'nix log /nix/store/jqvajznhf1l71xki56jjk8hcjh101fwa-emacs-straight-packages.json.drv'.
(use '--show-trace' to show detailed location information)

In reply to@mon:tchncs.de

Well, hello again! I'm starting to have some time again which is why I'm prograrmming some hobby projects lately, mainly using Idris 2, and I thought to boot up Doom Emacs (i don't yet have enough free time to start working on the documentation PR again unfortrunately, though i see you're making some progress, though somewhat slow. keep going!). For whatever reason, the pictured error below appears when running idris2-mode. But... I do depend on prop-menu in my configuration:

doom-emacs = {
  enable = true;
  doomPrivateDir = ./doom;
  extraPackages = [ pkgs.mu ];
  emacsPackage = pkgs.emacsPgtkNativeComp;
  emacsPackagesOverlay = self: super: {
    idris2-mode = self.trivialBuild {
      pname = "idris2-mode";
      ename = "idris2-mode";
      version = "0.0.0";
      buildInputs = [ self.prop-menu ];
      src = pkgs.fetchFromGitHub {
        owner = "idris-community";
        repo = "idris2-mode";
        rev = "4a3f9cdb1a155da59824e39f0ac78ccf72f2ca97";
        sha256 = "sha256-TxsGaG2fBRWWP9aas59kiNnUVD4ZdNlwwaFbM4+n81c=";
      };
    };
  };
};

any idea what's going wrong?

In reply to @ckie:ckie.dev
Gavin R: my list

I was having trouble installing (package! hyperbole), due to the following error during the nix-straight build:

       > ERROR: doom-emacs build resulted in files being written in $HOME of the build sandbox.
       > Contents of $HOME:
       > /build/tmp.9YIYoZ1pyj
       > /build/tmp.9YIYoZ1pyj/.hyperb

I solved this by, instead of using package!, adding pkgs.emacsPackages.hyperbole to the programs.doom-emacs.extraPackages list. No issues so far.

AFAIU, all I'm losing here are the configuration options of package! which I don't use and are mostly redundant anyway.

I'm thinking of similarly migrating all of my other package!s as well, as it should greatly simplify and reduce bugs in their installation; they will be built by one package (nix) manager instead of "3" (nix, nix-straight, nix-doom-emacs).

Is this a good idea? ckie (they/them) k0kada (he/him)

In reply to @hab25:matrix.org

I was having trouble installing (package! hyperbole), due to the following error during the nix-straight build:

       > ERROR: doom-emacs build resulted in files being written in $HOME of the build sandbox.
       > Contents of $HOME:
       > /build/tmp.9YIYoZ1pyj
       > /build/tmp.9YIYoZ1pyj/.hyperb

I solved this by, instead of using package!, adding pkgs.emacsPackages.hyperbole to the programs.doom-emacs.extraPackages list. No issues so far.

AFAIU, all I'm losing here are the configuration options of package! which I don't use and are mostly redundant anyway.

I'm thinking of similarly migrating all of my other package!s as well, as it should greatly simplify and reduce bugs in their installation; they will be built by one package (nix) manager instead of "3" (nix, nix-straight, nix-doom-emacs).

Is this a good idea? ckie (they/them) k0kada (he/him)

In reply to @hab25:matrix.org

I was having trouble installing (package! hyperbole), due to the following error during the nix-straight build:

       > ERROR: doom-emacs build resulted in files being written in $HOME of the build sandbox.
       > Contents of $HOME:
       > /build/tmp.9YIYoZ1pyj
       > /build/tmp.9YIYoZ1pyj/.hyperb

I solved this by, instead of using package!, adding pkgs.emacsPackages.hyperbole to the programs.doom-emacs.extraPackages list. No issues so far.

AFAIU, all I'm losing here are the configuration options of package! which I don't use and are mostly redundant anyway.

I'm thinking of similarly migrating all of my other package!s as well, as it should greatly simplify and reduce bugs in their installation; they will be built by one package (nix) manager instead of "3" (nix, nix-straight, nix-doom-emacs).

Is this a good idea? ckie (they/them) k0kada (he/him)

In reply to @hab25:matrix.org
I think it's a useful check, avoids hard to debug problems in the illegitimate cases. But what about directing users to prefer using extraPackages instead of `(package!)`, as I described?

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with NDE own code checks

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with NDE own code

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with doom-emacs own code

In reply to @k0kada:matrix.org

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with doom-emacs own code