nvim-neorg / nixpkgs-neorg-overlay Goto Github PK
View Code? Open in Web Editor NEWNixpkgs overlay for Neorg and related packages
License: MIT License
Nixpkgs overlay for Neorg and related packages
License: MIT License
The neorg
and tree-sitter-norg
used in the overlay are incompatible, resulting in invalid node type
errors. This is probably due to the refactors due to 1.0, but it can temporarily be fixed by using the dev
branch of tree-sitter-norg
.
When using the overlay to setup a neovim configuration in home-manager with Neorg, the plugin (even with only the core.defaults
module loaded) doesn't work and prints a warning about lua-utils
being not found. No neorg module is loaded, and there is no treesitter highlighting.
The same issue occurs with the neorg
package on nixpkgs (I used this overlay hoping not to encounter the same issue).
This seems related to the switch to neorg version 8. Maybe there are new dependencies to declare for the neorg package on nixpkgs and in this overlay.
I tried to add neorg's dependencies (to my knowledge lua-utils
nvim-nio
nui-nvim
plenary-nvim
as plugins explicitly in the plugins
field of my neovim home-manager config. I imported lua-utils
manually with buildVimPlugin
because it is not provided in nixpkgs or this overlay. I end up with partially working neorg (mainly treesitter highlighting) but most modules fail to load.
I have some remarks on the overlay technique, and thought about on how to clean it up a bit.
{ vimPlugins = prev.vimPlugins // { … } }
should probably replaced with:
{
vimPlugins = prev.vimPlugins.extend (f: p: {
neorg = p.neorg.overrideAttrs (a: {
dependencies = [ f.plenary-nvim ];
version = neorg.rev;
src = neorg;
});
neorg-telescope = final.vimUtils.buildVimPluginFrom2Nix {
dependencies = [ f.telescope-nvim f.neorg ];
pname = "neorg-telescope";
version = neorg-telescope.rev;
src = neorg-telescope;
};
});
}
I got bitten with overriding vimPlugins
without extend
before, because when I was using non-overriden plugins that had some overriden plugins as dependencies, they ended up in the pack path twice, leading to conflicts. extend
ensures that there is only ever one derivation. Right now this is a theoretical issue though, as no plugin in nixpkgs depends on neorg
, and neorg-telescope
is not in nixpkgs yet, but this should future-proof for when these conditions change. I'm not 100% sure if neorg above should be defined with overrideAttrs
though, I think a fresh buildVimPluginFrom2Nix
would also work.
I failed so far to properly overlay them, just overriding the attrs that are visible in the end (e.g. tree-sitter.{built,all}Grammars
, tree-sitter-grammars
etc.) didn't have the intended effect (in particular, the withPlugins functions get passed-in non-overriden versions of my overriden grammars). I'm not completely sure why this is, but I just couldn't make it work. Therefore I'd suggest to not do it, and put the grammars somewhere top-level. It's not an issue to refer to "external" grammars in the withPlugins closure, e.g. from my config:
(nvim-treesitter.withPlugins (p:
(attrValues (removeAttrs p [
"tree-sitter-perl" # highlighting issues, e.g. in "${…}", also missing indent
"tree-sitter-norg"
"tree-sitter-bash"
"tree-sitter-kotlin"
])) ++ [
final.tree-sitter-norg
final.tree-sitter-norg-meta
final.p-tree-sitter-grammars.tree-sitter-bash
final.p-tree-sitter-grammars.tree-sitter-kotlin
]))
I experimented with overriding nvim-treesitter
in a way that would allow the overlay to express that neorg
depends on it with the neorg parsers added automatically. It broke when the user also put nvim-tressiter
with some plugins top-level though, but I didn't give up yet. It would look something like this:
with inputs;
let
grammars = {
tree-sitter-norg = norg.defaultPackage.${final.system};
tree-sitter-norg-meta = norg-meta.defaultPackage.${final.system};
};
in {
vimPlugins = prev.vimPlugins.extend (f: p: {
nvim-treesitter = p.nvim-treesitter.overrideAttrs (a: {
passthru.withPlugins = grammarFn:
a.passthru.withPlugins (plugins:
(grammarFn plugins)
++ [ grammars.tree-sitter-norg grammars.tree-sitter-norg-meta ]);
});
neorg = p.neorg.overrideAttrs (a: {
dependencies = (a.dependencies or [ ])
++ [ f.plenary-nvim (f.nvim-treesitter.withPlugins (_: [ ])) ];
version = neorg.rev;
src = neorg;
});
neorg-telescope = final.vimUtils.buildVimPluginFrom2Nix {
dependencies = [ f.telescope-nvim f.neorg ];
pname = "neorg-telescope";
version = neorg-telescope.rev;
src = neorg-telescope;
};
});
}
(N.B. nvim-treesitter.withPlugins always adds norg grammars to the list, but I don't see a reason for users pulling in this overlay to not want that)
This would then enable to simplify the instructions to just adding vimPlugins.neorg
and the tree-sitter business would all be solved automatically.
What do you think? If that sounds good to you I'd like to take a stab and prepare another PR.
Cheers
Hey,
first of all thanks for starting a flake/overlay!
I'm unable to consume it though, because it doesn't handle system
properly. See attached stack trace [^1].
The way it is now only works in impure contexts, e.g. when using interactively (devShell, top level nix build, ...), or when passed-in late into nixos modules via nixpkgs.overlays
, as you showed in the README, I guess (AFAIK system
is pinned to a specific value in this context, appearing in args.system). My flake is structured differently, where packages and overlays are defined independently (producing pkgs and an overlay itself as outputs), and then multiple nixos configurations draw from these. Additionally, but somewhat unrelatedly, the nixos configurations are different systems.
The issue is actually in upstream flakes, e.g.: https://github.com/nvim-neorg/tree-sitter-norg/blob/main/flake.nix#L30. The second importing of nixpkgs outside of the eachSystem scope. They should define distinct packages on defaultPackage.x86_64-linux, defaultPackage.aarch64-linux, and so on.
Also I think you shouldn't prev.vimPlugins // { ... }
as vimPlugins is extensible. I do the following for vimPlugins overlays:
final: prev: {
vimPlugins = prev.vimPlugins.extend (f: p: {
neorg = final.vimUtils.buildVimPluginFrom2Nix { ... };
});
}
This approach has the advantage of affecting other plugins that depend on your overrides.
I found overriding tree-sitter-grammars a hard nut to crack - merging allGrammars, builtGrammars and tree-sitter-grammars was not enough to have them appear/override in all instances, as you noted e.g. that p: builtins.attrValues p
is not working, so I would probably not do it at all. AFAICS the issue is that the sources for these attributes are let bindings in the tree-sitter derivation and are not overridable. Instead, I would define them top-level and change the README to recommend nvim-treesitter.withPlugins (p: [p.unrelated-tree-sitter-grammar pkgs.tree-sitter-norg pkgs.tree-sitter-norg-meta pkgs.tree-sitter-norg-table])
I'd like to take a stab - are you open to look at related PRs for this?
Cheers
[^1:]
$ nix build .#tree-sitter-grammars.tree-sitter-norg --show-trace
error: attribute 'currentSystem' missing
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/impure.nix:17:43:
16| # (build, in GNU Autotools parlance) platform.
17| localSystem ? { system = args.system or builtins.currentSystem; }
| ^
18|
… while evaluating anonymous lambda
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/default.nix:7:1:
6|
7| { # Args just for stdenvs' usage
| ^
8| lib
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/default.nix:127:12:
126|
127| stages = stdenvStages {
| ^
128| inherit lib localSystem crossSystem config overlays crossOverlays;
… while evaluating 'reverseList'
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/lib/lists.nix:393:17:
392| */
393| reverseList = xs:
| ^
394| let l = length xs; in genList (n: elemAt xs (l - n - 1)) l;
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:85:6:
84| // (stageFun prevStage))
85| (lib.lists.reverseList stageFuns);
| ^
86|
… while evaluating 'imap1'
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/lib/lists.nix:116:14:
115| */
116| imap1 = f: list: genList (n: f (n + 1) (elemAt list n)) (length list);
| ^
117|
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:78:30:
77| # isn't already set.
78| withAllowCustomOverrides = lib.lists.imap1
| ^
79| (index: stageFun: prevStage:
… while evaluating 'go'
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:63:18:
62| len = builtins.length list;
63| go = pred: n:
| ^
64| if n == len
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:72:13:
71| lapp = lnul cur;
72| cur = go lapp 0;
| ^
73| in cur;
… while evaluating 'dfold'
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:60:27:
59| */
60| dfold = op: lnul: rnul: list:
| ^
61| let
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:142:4:
141|
142| in dfold folder postStage (_: {}) withAllowCustomOverrides
| ^
… while evaluating anonymous lambda
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/stdenv/booter.nix:42:1:
41| # other words, this does a foldr not foldl.
42| stageFuns: let
| ^
43|
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/default.nix:131:10:
130|
131| pkgs = boot stages;
| ^
132|
… while evaluating anonymous lambda
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/default.nix:58:108:
57| throwIfNot (lib.isList crossOverlays) "The crossOverlays argument to nixpkgs must be a list."
58| lib.foldr (x: throwIfNot (lib.isFunction x) "All crossOverlays passed to nixpkgs must be functions.") (r: r) crossOverlays
| ^
59| ;
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/default.nix:133:4:
132|
133| in checked pkgs
| ^
… while evaluating anonymous lambda
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/default.nix:19:1:
18|
19| { # The system packages will be built on. See the manual for the
| ^
20| # subtle division of labor between these two `*System`s and the three
… from call site
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/impure.nix:82:1:
81|
82| import ./. (builtins.removeAttrs args [ "system" ] // {
| ^
83| inherit config overlays localSystem;
… while evaluating anonymous lambda
at /nix/store/bn14fy2mc2p1q44681il8idfv5fr5x3z-source/pkgs/top-level/impure.nix:14:1:
13|
14| { # We put legacy `system` into `localSystem`, if `localSystem` was not passed.
| ^
15| # If neither is passed, assume we are building packages on the current
… from call site
at /nix/store/3s59raz9x27y20ddgc65aslp657cvj0a-source/flake.nix:30:28:
29| };
30| })) // (let pkgs = import nixpkgs { }; in { defaultPackage = defaultPackage pkgs; });
| ^
31| }
… while evaluating 'defaultPackage'
at /nix/store/3s59raz9x27y20ddgc65aslp657cvj0a-source/flake.nix:12:24:
11| let
12| defaultPackage = pkgs: pkgs.callPackage (nixpkgs + "/pkgs/development/tools/parsing/tree-sitter/grammar.nix") { } {
| ^
13| language = "norg";
… from call site
at /nix/store/3s59raz9x27y20ddgc65aslp657cvj0a-source/flake.nix:30:70:
29| };
30| })) // (let pkgs = import nixpkgs { }; in { defaultPackage = defaultPackage pkgs; });
| ^
31| }
… while evaluating the attribute 'defaultPackage'
at /nix/store/3s59raz9x27y20ddgc65aslp657cvj0a-source/flake.nix:30:53:
29| };
30| })) // (let pkgs = import nixpkgs { }; in { defaultPackage = defaultPackage pkgs; });
| ^
31| }
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.