`nestedLiteral` converts a `literalExpression` into a `toPretty` style
pretty-printer.
`nestedLiteralLua` composes `nestedLiteral` and `literalLua` together.
Replace `mkNeovimPlugin`'s `installPackage` parameter with a new
internal module option: `packageDecorator`.
The option is a function that applies some transformation to
`cfg.package`'s value before it is installed.
Instead of relying on option `apply` functions to coerce the value to
rawLua, this can be done in the type's merge function.
Inspired by `types.coercedTo` in nixpkgs.
End-users have ran into issues before when attempting to re-use a `lib`
from elsewhere in nixvim's configuration.
If a `lib` without the `nixvim` extension is used, this assertion will
inform the user that this isn't supported.
In the future we can also provide better ways for end-users to overlay
their own lib with nixvim's extensions, but this is not yet implemented.
Co-authored-by: Gaétan Lepage <33058747+GaetanLepage@users.noreply.github.com>
This minimal implementation allows `nixpkgs.pkgs` to be defined, but
does not implement evaluating an instance from a pkgsPath when _not_
defined.
The `defaultPkgs` specialArg is dropped in favour of `nixpkgs.pkgs`
being defined. If it's not defined, an assertion is thrown.
In the future, a nixpkgs source path can be supplied, defaulting to the
flake's `inputs.nixpkgs`. Along with other `nixpkgs.*` options, this
will allow a `pkgs` instance to be evaluated within the module eval.
Previously the deprecated builders would warn when used on a lib _with_
`pkgs`, but were simply not present on a lib _without_ `pkgs`.
Now, they are always present, but will throw when evaluated on a lib
_without_ `pkgs`.
In the two places where our "helpers" lib is exclusively internal
(flake module args and building the docs), we no longer supply `pkgs`.
In the other 4 locations, we now note why we still do in a comment.
This commit adds a `plugins.<name>.luaConfig` section controlling the
plugin specific configuration.
The section contains the internal `init` option, containing the plugin's
initialization code.
It also contains the public `pre` and `post` options, that allow to add
code before & after the `init` section
Finally, it contains the `final` option, being the concatenation of the
three previous options.
These functions had very similar bugs: they didn't check if their chosen
"close token" was already present in the string they're escaping.
I went ahead and did the work implied by the TODOs: search for a "close
token" that is *not* in the original string. Pretty simple concept, but
it turned into an annoying amount of code. I couldn't find anything in
upstream nixpkgs lib, or some clever insight about lua/vimscript that
makes this work unecessary, but I'll be thrilled (and a little bummed
about a wasted afternoon) to learn about something.
Splits everything that depends on a `pkgs` instance into an optional
attrs, allowing `helpers.nix` to be bootstrapped without `pkgs`.
This required some refactoring:
- `modules.specialArgs` is only available when `pkgs` is used
- `modules.specialArgsWith` now requires `defaultPkgs` be provided
- `builders.*` now have `*With` variants that take `pkgs` as an argument
and a `withPkgs` function that returns the old interface
- Had to define the fixed part of `builders` outside the attrs for now,
to avoid infinite recursion.
- The old `builders` are now deprecated, and print a warning when
evaluated
- `withOptoinalFns` was introduced to merge the optional attrs into the
final lib.
The old `default.nix` is inlined into the "lib" flake-module, which is
the only place it was used.
This allows "helpers" to take its rightful place at the root of `./lib` 👑
Instead of maintainers providing an actual `defaultPackage`, they should
specify the pkg name which we'll use when calling `lib.mkPackageOption`.
This makes `mkVimPlugin` and `mkNeovimPlugin` compliant with #1950.
Since cbd1003d9d I'm able to add _some_
invalid config definitions to modules the tests are using and get no
build error.
For example `extraConfigLua = null;` should produce an invalid type
error, but doesn't.
One less visible change in that commit is the move away from using the
"standalone" wrapper (`makeNixvimWithModule`), which implicitly sets
`wrapRc = true`.
Adding back `wrapRc` to the tests seems to fix the issue, however this
makes me wonder if there's an underlying issue with wrapping/not-wrapping?
Perhaps we've simply uncovered a long-standing eval issue that is masked
over by using `wrapRc`?
Warnings and assertions defined as `config.warnings` and `config.assertions`
respectively will be checked as part of the test derivation, instead of
when evaluating the modules.
Adds new `checkWarnings` and `checkAssertions` test options (default true).
