Feature request: consume as raw Nix (not flake)

[mightyiam]

Related #2186.

I'd like to be able to consume NixVim by importing some Nix files from this repository instead of by accessing flake outputs.

@jfly @toastal

[MattSturgeon]

We already have default.nix that can be consumed without flakes.

It uses flake-compat to fetch the inputs pinned by our flake.lock.

[mightyiam]

In theory, NixVim can be provided as a Nixpkgs overlay. That is how I would like to consume it, I think.

NixVim only happens to depend on flake-parts (hopefully not to a great extent), not fundamentally, I would say.

How deep is the reliance on flake-parts, roughly?

[MattSturgeon]

Flake Parts is only used to define the flake outputs.

Nixvim doesn't really have any package outputs, so a Nixpkgs overlay is unnecessary. We do already have a Nixpkgs-lib overlay, which extends lib with lib.nixvim.

lib.nixvim.evalNixvim is the main entrypoint to a standalone Nixvim configuration. Currently, it depends on the flake inputs only for defining the nixpkgs.source option default (it defaults to inputs.nixpkgs).

If you explicitly define nixpkgs.source or nixpkgs.pkgs, then that shouldn't be evaluated and it should be possible to use Nixvim without referencing any of its flake inputs or outputs.

We could also look into having nixpkgs.source read directly from flake.lock when Nixvim's lib is evaluated in a non-flake environment.

I'm away from my PC currently so can't help more explicitly, but you can look into how we instantiate our Nixvim lib (in the lib/ directory and the relevant flake-parts module).

Edit: I'd start by evaluating the overlay with { flake = {}; } and seeing which options explode when you use evalNixvim.
Edit2: looks like options that depends on flake include the wrapper modules, the manpage docs, and nixpkgs.source

[mightyiam]

Good thinking. Thank you for checking. I'll try to get 'round to this, unless you want to do it.

[mightyiam]

Another concern may be. When using via flake output, the nixpkgs is by default locked to what this project declares to be a supported good working rev. I' not sure how that would be achieved when consuming as vanilla. I suppose the default for nixpkgs.source in that case could be a runtime fetched Nixpkgs rev, perhaps taken straight from the flake lockfile. How does that sound?

[MattSturgeon]

Yes. We'd have to make a decision for what default to use when flake is not available.

1. Read the lockfile and fetch with fetchTree (matches flake internals)
2. Read the lockfile and fetch with fetchtarball (broarder compatibility)
3. Default to <nixpkgs> (from the impure NIX_PATH)
4. Don't define a default (will throw "option nixpkgs.source used but not defined")

I think my preference would be to have the default still read from the lockfile for consistency.

We'll have to ask similar questions for the wrapper modules, which inherit a few flake inputs and outputs.

We'll also need to refactor the manpage docs, so that we don't need to get it from flake outputs. E.g. a loose package file, or have it built by a nixvim module.

[jfly]

@mightyiam, could you explain why you want to be able to do this?

[mightyiam]

For myself, to reduce the size of my flake lockfile. For others, so that they'll be able to use without reliance on flakes.

[jfly]

For myself, to reduce the size of my flake lockfile.

Doesn't nix flake's existing inputs.follows mechanism give you the control you want already?

For others, so that they'll be able to use without reliance on flakes.

@MattSturgeon mentioned that there's a "default.nix that can be consumed without flakes".

[mightyiam]

Yes, inputs.follows would do that, but if the input (NixVim in this case) adds a new input I might not notice and end up with a new lockfile item. With flake=false that cannot happen.

The default.nix uses flake-compat. That ends up fetching the flake inputs using vanilla nix eval time fetchers (probably), and it does so without giving me an opportunity to override them, I think.