[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packaging baby-steps
From: |
Antlers |
Subject: |
Re: Packaging baby-steps |
Date: |
Tue, 10 May 2022 01:00:00 +0000 (UTC) |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Packaging baby-steps,
Antlers <=