I am not sure why I introduced it, probably to avoid touching the
wrapper interface too much and massage arguments beforehand.
With the `finalAttrs` pattern, one can more easily override the resulting neovim derivation without
having to preprocess arguments first so `makeNeovimConfig` just ends up
making the interface more confusing.
Cargo's `[lints]` table is a cargo-only feature: cargo translates the
entries into `-A`/`-W`/`-D`/`-F` rustc flags before invoking the
compiler. Since buildRustCrate calls rustc directly, these lints were
silently ignored, forcing users to duplicate them as raw flags in
`extraRustcOpts`.
Accept a `lints` attr with the same shape as the Cargo.toml section
(tool → lint name → level string or `{ level, priority }` attrset),
translate it to rustc flags in Nix, and append to the rustc command
line. Entries are sorted by ascending priority so lower-priority lint
groups are emitted first and can be overridden by more specific lints,
matching cargo's behaviour.
The `capLints` default changes from `"allow"` to `null`, resolved to
`"allow"` when `lints` is empty (the usual case for third-party
dependencies) and `"forbid"` when `lints` is set — otherwise a
`deny`/`forbid` lint would be silently capped and the table would be a
no-op. Explicit `capLints` still overrides. This is the same model
cargo uses: your own crate's `[lints]` always apply; only
dependencies get `--cap-lints allow`.
Generators like crate2nix can populate `lints` directly from the
manifest at generation time.
lib.sh previously hardcoded `--cap-lints allow` in both build_lib and
build_bin. Since rustc only honours the first `--cap-lints` it sees,
appending a different level via `extraRustcOpts` had no effect, making
it impossible to run clippy (or any lint-based tooling) through
buildRustCrate without wrapper scripts that strip the argument.
This adds a `capLints` parameter (default `"allow"`, preserving current
behaviour) that can be set per-crate or via `.override`:
(myCrate { }).override { capLints = "warn"; }
Not every Jenkins installation needs any package included in PATH. Drop
the packages from `services.jenkins.packages` and leave the decision up
to the user instead.
Add a release note to 26.05 in order to notify users.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Neovim currently resolves its lua dependencies at buildtime in the wrapper, which causes some trouble as it's difficult to debug or replicate the result outside without rebuilding the wrapper.
This change makes lua dependencies available at evaltime.
We can thus build a luaEnv to avoid building a long LUA_PATH which can help with runtime perf.
The drawback is that we now need to engrave in nix the default LUA_PATH for the various lua interpreters.
This is what I had initially tried to avoid but the tradeoff proved annoying.
As far as neovim is concerned, we only care about the lua 5.1 and luajit interpreters whose defaults only slightly differ for cpath IIRC.
So it should mostly transparent except for one or two plugins in which case we can update "getLuaPath" on a per interpreter basis.
