Bringing the Neovim package up to date

Bringing the Neovim package up to date

[HiPhish]

Hello everyone,

I have been using the Guix package manager on Kubuntu for a while now and I'm 
relatively familiar with it, so I wanted to try my hand on updating the Neovim 
package; Neovim is my package manager of choice and at the moment I'm using an 
apt PPA. I would like to get rid of the PPA and rely on Guix instead, using 
apt only for what is necessary for the system.

Currently Neovim on Guix is at version 0.2.0, but the most recent release is 
0.3.1; I want to update the package. I would be grateful is someone could 
assist me with guidance on this endeavour.

The first thing I noticed is that the dependencies are wrong. It specifies Lua 
5.2 as an input, and the corresponding Lua 5.2 libraries like lpeg. However, 
Neovim requires Lua 5.1, and Lua minor releases are not backwards-compatible. 
So this needs to be fixed, which also means that we need to define new 
packages.

For lua5.1-lpeg and lua5.1-bitop this should be simple enough, just call the 
function that generates the package with lua-5.1 as the Lua version. The 
definition of lua5.1-libmpack would be a bit more involved, but still 
straight-forward.

Another thing is that Neovim can be built both with Lua 5.1, or LuaJIT. Using 
LuaJIT would be preferable, is there a way to define the above libraries with 
lua-5.1 as input, but then swap it out for luajit in the definition of Neovim?

On an unrelated note, the coding style always imports everything from a 
module. This makes it really hard for someone unfamiliar with Guix to know 
where the various procedures, variables and macros come from. Is there a 
reason you don't explicitly import identifiers with `#:select`? In my own code 
I always prefer that style because in a month I will have no idea where any of 
that stuff comes from.

Re: Bringing the Neovim package up to date

[Ludovic Courtès]

Hello!

HiPhish <hiphish@posteo.de> skribis:

> Currently Neovim on Guix is at version 0.2.0, but the most recent release is 
> 0.3.1; I want to update the package. I would be grateful is someone could 
> assist me with guidance on this endeavour.

Sure!  While you’re trying things out, you may find that IRC will be
better suited to get guidance and information on how to debug issues.

> The first thing I noticed is that the dependencies are wrong. It specifies Lua 
> 5.2 as an input, and the corresponding Lua 5.2 libraries like lpeg. However, 
> Neovim requires Lua 5.1, and Lua minor releases are not backwards-compatible. 
> So this needs to be fixed, which also means that we need to define new 
> packages.
>
> For lua5.1-lpeg and lua5.1-bitop this should be simple enough, just call the 
> function that generates the package with lua-5.1 as the Lua version. The 
> definition of lua5.1-libmpack would be a bit more involved, but still 
> straight-forward.
>
> Another thing is that Neovim can be built both with Lua 5.1, or LuaJIT. Using 
> LuaJIT would be preferable, is there a way to define the above libraries with 
> lua-5.1 as input, but then swap it out for luajit in the definition of Neovim?

Yes.  In short you would define the new package to “inherit” from
‘lua-5.1’, and you would change its ‘inputs’ field.  There are examples
of that in the code.  Let us know if anything’s unclear!

> On an unrelated note, the coding style always imports everything from a 
> module. This makes it really hard for someone unfamiliar with Guix to know 
> where the various procedures, variables and macros come from. Is there a 
> reason you don't explicitly import identifiers with `#:select`? In my own code 
> I always prefer that style because in a month I will have no idea where any of 
> that stuff comes from.

We cannot #:select from (gnu packages …) modules due to the way Guile
handles circular dependencies among modules.  However we could use
select more frequently for other modules.

I don’t know if there’s anything similar for (Neo)Vim, but those of us
who use Emacs also use Geiser, which displays in the “mode line” at the
bottom the module that provides a given variable.

Thanks,
Ludo’.

Re: Bringing the Neovim package up to date

[HiPhish]

On Monday, 2018-09-10 14:27:02 CEST Ludovic Courtès wrote:
> Sure!  While you’re trying things out, you may find that IRC will be
> better suited to get guidance and information on how to debug issues.
OK, noted.

> Yes.  In short you would define the new package to “inherit” from
> ‘lua-5.1’, and you would change its ‘inputs’ field.  There are examples
> of that in the code.  Let us know if anything’s unclear!
I'll give it a try, I just wanted to know if there is maybe something more to 
it to be aware of.

> We cannot #:select from (gnu packages …) modules due to the way Guile
> handles circular dependencies among modules.  However we could use
> select more frequently for other modules.
I didn't know about circular dependencies. I mainly wanted to know if there is 
maybe a reason or guideline against using `#:select` and whether package 
definitions like that might get rejected.

> I don’t know if there’s anything similar for (Neo)Vim, but those of us
> who use Emacs also use Geiser, which displays in the “mode line” at the
> bottom the module that provides a given variable.
That explains a lot. I know about Geiser, but Vim is the editor I have settled 
in, I feel that switching would be just as much work as porting Geiser to 
Neovim at this point. From what I understand Geiser has two parts: the Emacs 
plugin and the actual Geiser process which is written in Scheme. "Porting" 
Geiser would only require re-writing the editor interface for Neovim while the 
Scheme backend could be kept. It's just that no one has ever felt the need to 
do that, Lisp programmers who use Vim are very rare.

Is there a way to get the module from a REPL? I can run a REPL in my editor, 
that's the crutch I have been using so far. (IMO tying the readability of the 
source code to the development environment is a bad idea, that's what IDEs 
always end up doing)

Re: Bringing the Neovim package up to date

[Ludovic Courtès]

Hello,

HiPhish <hiphish@posteo.de> skribis:

> Is there a way to get the module from a REPL? I can run a REPL in my editor, 
> that's the crutch I have been using so far. (IMO tying the readability of the 
> source code to the development environment is a bad idea, that's what IDEs 
> always end up doing)

From the REPL you can use the “apropos” command:

  scheme@(guile-user)> ,apropos mkdir
  (guile): mkdir	#<procedure mkdir (_ #:optional _)>
  (guix build utils): mkdir-p	#<procedure mkdir-p (dir)>

But for Guix, you can always run “./pre-inst-env guile” to open a REPL
in the context of Guix (or run “guix repl”), and there you can “get into
a module” like this:

  ,m (gnu packages base)

HTH!

Ludo’.