Packaging baby-steps

Packaging baby-steps

[Cássio Tavares]

Hello!

I'm new to Guix, and I chose to use it for the principles of it
(linux-libre and such), but against a better judgement of my technical
incompetence. So.

A lot of things I was used to in more mainstream distros are not packaged
here and, after reading the manual and learning about how I could write my
own packages, and with `guix import` for short-cut, I decided to give it a
try. Then another. Then another — in all of them I failed miserably, and
couldn't make any sense of the log files…

I let it go for a while, but then I thought that some packages should be
easier to write than the ones I tried. So, I started looking around for
what I could do, and I realised: there are no plugin managers for neovim.
Then I went to GitHub, and looked at `*packer.nvim*
<https://github.com/wbthomason/packer.nvim>`, and… …is it feasible? — this
is how `*packer.nvim*` is supposed to be installed on regular, imperative
distros:

*Step One:* issue this command:


*git clone --depth 1 https://github.com/wbthomason/packer.nvim\
<https://github.com/wbthomason/packer.nvim\>
~/.local/share/nvim/site/pack/packer/start/packer.nvim*


*Step Two:* write a `*/path/to/neovim/plugins/lua/plugins.lua*` that
contains:

*-- Only required if you have packer configured as `opt`*





*vim.cmd [[packadd packer.nvim]]return
require('packer').startup(function()  -- Packer can manage itself  use
'wbthomason/packer.nvim'*

*  -- Configure other plugins*

  *…*
*end)*



*Step three:* include this line —  `*lua require('plugins')*` — in the file
`*init.vim*`, wherever it is.

*My questions:*

   1. *Step one* seems to be just a simple file download to an appropriate
   directory — is that assessment correct?
   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?
   3. *Step two*, I imagine, should be easy if there isn't already a `
   *plugin.lua*` file, right? What if there is?
   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*`?
   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?
   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?
   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?

I will be grateful to anyone who helps me to write my first package...
Regards,
Cássio
-----
Faculdade de Letras - UFG
*“*
*Ou a gente se Raôni, ou a gente se Sting**”*

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.