Re: Packaging baby-steps

[Antlers]

Hi! Sorry for the late bump, but if your still interested, I'd be glad answer 
some questions.

Any neovim plugins are likely installed in nearly the same way, and we may 
actually be able to extend `guix import` to create packages for arbitrary 
plugins within Guix itself (which likes to be the one and only package 
manager). This is how eg. emacs packages are handled, and packaging a couple of 
individual plugins first will still help to make the process clear.

   1. *Step one* seems to be just a simple file download to an appropriate
   directory — is that assessment correct?

Yep, there are dedicated functions in the module (guix git-download) which will 
make it a breeze to turn any given repo URL into what's known as an origin-- 
check out the great guix manual pages on package definitions and origins!

   2. If so, would it be hard to generalize this so that it can be
   installed either system-wide or per-user? I guess there is a Guix idiomatic
   way to accomplish what the above git command is doing, right?

Installation is a separate concern from downloading, which can kind of be seen 
in how each produces a separate object in the store- one containing the origin 
(repo), and one containing the "output" files.

   3. *Step two*, I imagine, should be easy if there isn't already a `
   *plugin.lua*` file, right? What if there is?

It's important to separate the activation and configuration of a plugin from 
it's installation. When init.vim calls "lua require(" plugin")", neovim looks 
for a matching file called plugin.lua and loads it, so plugin.lua is actually 
kinda just part of init.vim that's been modularized out and interpreted as 
lua-- note now that it contains configuration for packer, like what plugins to 
install.

We could still create this kind of activation / configuration code for the 
user, but it would be more of a Guix home kinda thing, beyond the scope of eg. 
a system-wide package.

As a package manager, it's just Guix's job to get Packer into some sort of 
search path, so that when the user runs "return 
require('packer').startup(whatever())", neovim knows where to find the file 
matching "require('packer')", probably "packer.lua" but possibly "packer.vim" 
(I haven't checked).

   4. Is it acceptable if the installation process doesn't look into the
   plugins directory-tree to try and automatically create entries for them in
   `*plugin.lua*`?

Once again a Guix home issue, but if we were to go there:

When each plugin is packaged, it becomes an entry in the store, and when it's 
installed, it's made available in a search path, but still exists primarily in 
the store (/gnu/guix) or worst-case as a symlink in a directory like plugins/. 
We could:

a.) Create a symlink for each packaged-plugin matching the plugins name, like 
plugins/packer.lua, pointing to the equivalent file in the store.

b.) Create a single file called guix.lua which contains an entry for each 
package we wish to install, directly referencing it's oath in he store 
("require("/gnu/store/..."). This would be regenerated whenever you run "guix 
home reconfigure", and achieved via service extensions, but is once again 
beyond the scope of baby steps. A user could import this file and have all 
their plugins activated.

This is complicated by the fact that the import statement isn't the one in 
init.vim, but actually part of plugin.lua, and contains configuration in the 
"startup" field!, which we really want to keep seperate from activation if we 
can. I'm not sure if we can seperate these, because I'm not sure why that 
configuration needs to be part of the "startup" function, so I'd default to 
just leaving it to the user to do.

   5. Also, in *Step two*, the first line in `*plugin.lua*` is required
   only if a certain condition is met. Is it OK to leave it there if the
   condition is not met?

Uh, tbh I'm not familiar with what optional plugins are in this context-- it's 
probably okay? I use neovim daily, but don't use any packages ¯\_(ツ)_/¯. I'd 
say it's a "try and find out, then try it without" kinda deal, and leave it out 
if it causes any issues or isn't necessary.

   6. The problems in *Step three* seem to be the same as in *Step two*.
   Except that maybe it could be assumed that, since `*neovim*` is a
   dependency, the file `*init.vim*` would necessarily exist?

Once again, installing a package is seperate from loading it; not every user 
will want to "require" every package that's installed system-wide, so barring 
am adventure into Guix home, we can just assume that the user will take 
responsibility for this step and just worry about where neovim looks for 
plugins when a user does try to require something (Somewhere in /usr for system 
wide plugins?)

   7. From what I could tell from `*packer.nvim*`'s repo, the only
   dependency is on neovim version 0.5 or later — is there anything else I
   would need to work on or check out?

Nah, if it really requires anything else it'll just not work when isolated with 
something like "guix shell -C neovim neovim-packer -- neovim" (putting aside 
plugins that packer download into your home directory, which would still be in 
the container), which can be sorted out later -- but it really shouldn't 
require anything that neovim doesn't already require at runtime.