guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bringing the Neovim package up to date


From: Ludovic Courtès
Subject: Re: Bringing the Neovim package up to date
Date: Mon, 10 Sep 2018 14:27:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello!

HiPhish <address@hidden> 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]