| 15 Dec 2022 |
ckie (they/them) | Gavin R: my list | 19:04:42 |
ribosomerocker | 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? i've checked the issues and there doesn't seem to be an issue like this, i assume this is just another case of my machine being cursed... | 19:49:09 |
ribosomerocker | well, except my issue, but that issue was solved with this exact piece of code | 19:51:53 |
| ribosomerocker changed their profile picture. | 19:53:08 |
Gavin R | In reply to @ckie:ckie.dev Gavin R: my list cool, thanks. why do you have your latex section commented out? | 21:41:01 |
ckie (they/them) | it's 5gb or something and latex errors are annoying as fuck | 21:41:19 |
Gavin R | ya i'm thinking about just copy/pasted my org tables from my CV into libreoffice and being done with it lol | 21:42:04 |
| 16 Dec 2022 |
ribosomerocker | Well, I've found nothing to fix it. I assume you guys don't know what's going on too? | 18:58:58 |
ckie (they/them) | ribosomerocker: you probably want a (package! prop-menu) | 22:17:39 |
| 17 Dec 2022 |
| @adam:valkor.net left the room. | 04:30:01 |
| 18 Dec 2022 |
@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)
| 10:17:25 |
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)
I still don't think we should have that $HOME check | 10:43:28 |
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)
* I still think we shouldn't have that $HOME check | 10:43:38 |
k0kada (he/him) | It does seem this is a legitimate case of a deps just building something and leaving dirty at the simulated $HOME we have | 10:44:06 |
@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? | 11:09:26 |
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? It is not in this particular case | 13:47:16 |
k0kada (he/him) |
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
| 13:48:00 |
k0kada (he/him) | *
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
| 13:48:06 |
k0kada (he/him) | *
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
| 13:48:56 |
@hab25:matrix.org | 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
Thanks! Do you have a specific issue in mind? | 14:03:54 |
k0kada (he/him) | No, but doom-emacs code is complex enough that I can imagine a few hard to debug issues to happen because you're not using the proper way to load a dependency | 14:05:50 |
k0kada (he/him) | I remember having issues using the wrong way to load a dependency in doom-emacs itself | 14:06:16 |
k0kada (he/him) | This was before using NDE | 14:06:32 |
k0kada (he/him) | Anyway, do what you want, but I wouldn't recommend | 14:06:47 |
k0kada (he/him) | * Anyway, do what you want, but I wouldn't recommend it | 14:06:52 |
k0kada (he/him) | There is a chance we already do this for NDE itself though, if yes forget what I said | 14:07:15 |
k0kada (he/him) | But only ckie (they/them) can answer this question | 14:07:25 |
@hab25:matrix.org | In reply to @k0kada:matrix.org No, but doom-emacs code is complex enough that I can imagine a few hard to debug issues to happen because you're not using the proper way to load a dependency True | 14:07:37 |
@hab25:matrix.org | Ok, thanks again! | 14:07:42 |
k0kada (he/him) | One possibly issue I can think right now is that maybe the deps will not be natively compiled | 14:08:51 |