Bootstrapping issues when relying on nfnl standard library

[sullyj3]

Hi there!

I have an nvim configuration that uses nfnl, and in particular makes use of the nfnl standard library.
It works great! However, when I attempted to clone the configuration to a new machine, I ran into a problem.

My plugins configuration can't access the nfnl standard library unless the nfnl plugin is already installed! So packer completely fails to start, crashing with a bunch of errors about requires and nil.

I had to go back to the first commit where I installed nfnl (before I started relying on the standard library) and do a PackerSync to get nfnl installed. Then going back to the latest commit, everything worked fine.

Does anyone have any experience dealing with this problem? Are there any recommended patterns, before I go off and start trying to solve it on my own?

[Olical]

Oh! You're very right! I've run into this with Aniseed and the way I got around it was basically to have a check in the entrypoint (init.lua etc) that checked if Aniseed was cloned into my pack path or not. If it wasn't I cloned it on the spot and then let my normal plugin management stuff kick in.

You could vendor the nfnl library into your repo (I'm sort of pushing "vendoring Lua for Neovim things is good and fine actually" a lot right now) but that is a little funny feeling.

I'll have a think about this / put together a little bootstrap snippet soon or someone else can beat me to it. I think since nfnl is such a fundamental part of people's Neovim configuration, we need to have a very good paved road for this sort of boot strapping.

Or we just make it really simple and vendor things 😅

I might experiment with something using (include :nfnl.core) (include docs) too which includes the module at compile time, inlining it into your module and removing the need for it to be installed at all in the wider system.

If you're only using one module in one place, that'll work for now really well. If you're using it in more placed Fennel won't dedupe the multiple include calls so you'll end up bloating things. You could also create a file under nfnl/core.fnl that only includes (include :nfnl.core) which is just like copying in the source yourself, ensuring you always have a copy of that module available in your locally committed Lua.

Just throwing lots of ideas around right now, not settled on what will be the best solution yet.

[sullyj3]

Cool, I think I'll play around with cloning, since I already do that for Packer. Let me know if you come up with something nicer!

[Olical]

Just a heads up, I've added :rtp-patterns to the config now, it defaults to including nfnl into your fennel search paths. See the readme / config docs for more info but basically you can tell nfnl to include other plugins in the search paths now when looking for modules to include or macros to load at compile time. This means you could use nfnl macros in your project at compile time / use include to inline things from nfnl from your plugin.

You might still need to copy nfnl into your project if you want to use it at runtime in a plugin, but you might be able to get away with a file like fnl/my-proj/nfnl/core.fnl containing (include :nfnl.core) then you can (require :my-proj.nfnl.core) and you'll have a vendored copy of nfnl.core in your project's Lua output you can use.

It does mean you have to create a kind of proxy .fnl file for each module you want to use from a dependency, but fits in nicely with the nfnl workflow.

[sullyj3]

Cool, thank you!