lib: don't duplicate nixpkgs' lib

[alfarelcynthesis]

The current implementation of nvf's custom lib uses nixpkgs' lib.extend function.

This is intended as an escape hatch for buggy behaviour in nixpkgs and adds unnecessary eval time.
As well, when I was initially looking at nvf's codebase, the use of the lib.nvim namespace obfuscated where functions were actually coming from in nvf's code, but this might be a nonissue depending on personal opinion.

This PR converts the codebase to a separate extensible fixed-point, implemented similarly to nixpkgs' lib, without being a direct extension of it.

This is fairly simple and imo actually reduces complexity with not having to keep around the extension function.
I think it's fair to call this a reduction in technical debt.

The current implementation is incomplete, since I want to know whether this might be accepted and, if so, whether to take the approach:

1. With a minimal diff that keeps the reduced eval time and prevents any the issues nixpkgs warns against, but doesn't improve code clarity (by separating the two libs explicitly).
   This means _module.args.lib = pkgs.lib // {nvim = self.lib;}, probably.
2. Which does all, with treewide changes from lib.nvim -> self.lib.

Sanity Checking

• I have updated the changelog as per my changes
  • This shouldn't change anything for users, since the version exposed by the flake already stripped nixpkgs out.
• I have tested, and self-reviewed my code
  • Reviewed a previous version which worked without issues, want advice before proceeding here and doing more thorough testing.
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • My changes are consistent with the rest of the codebase (in terms of style)
• If new changes are particularly complex:
  • My code includes comments in particularly complex areas
  • I have added a section in the manual
  • (For breaking changes) I have included a migration guide
    • No need for this to be breaking.
• Package(s) built:
  • .#nix (default package)
  • .#maximal
  • .#docs-html (manual, must build)
  • .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

🚀 Live preview deployed from 3e48f13

View it here:

Debug Information

Triggered by: alfarelcynthesis

HEAD at: no-extend-lib

Reruns: 1501

[alfarelcynthesis]

(@NotAShelf since I want opinions before marking this ready for (final) review)

[NotAShelf]

To be honest I'm not a huge fan of separating lib and nvf-lib, but I can see why one would want to. I'd like to defer to @horriblename as I'm currently too occupied irl to deal with large-scale refactors myself.

[horriblename]

I am completely out of my depth with this, the link gives some very scary warnings but gives no explanation on why, so I'm not really sure what to do with that info

If you can help me understand any of this it would be much appreciated :)