Neovim plugin/addon packaging

Neovim plugin/addon packaging

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

Greetings Guix,

I'd like to improve the experience of installing Neovim plugins/add-ons 
with Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search 
path so nvim (the Neovim executable name) will be able to find plugins 
installed by guix at …/share/nvim/site.

Currently, we only have one such package, neovim-syntastic. I'd like to 
add more. Many plugins are compatible with both vim and nvim. However, 
they search for plugins at different paths. Therefore, the vim-syntastic 
and neovim-syntastic packages, which use the copy-build-system, differ 
only in the destination directories of the install-plan (and changing 
"Vim" to "Neovim" in the description).

My initial inclination is to remove the duplication of maintaining two 
install-plans (and other arguments) by creating a procedure that would take 
as input a Vim package that uses copy-build-system and output a Neovim 
package with the install-plan re-written.

Perhaps that solution would be overwrought. How would you recommend 
handling this situation?

[0] https://issues.guix.gnu.org/48112

Best,
Jack

Re: Neovim plugin/addon packaging

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote:
> Greetings Guix,
> 
> I'd like to improve the experience of installing Neovim plugins/add-ons with
> Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so
> nvim (the Neovim executable name) will be able to find plugins installed by
> guix at …/share/nvim/site.

I guess my first question is does it work? I think I first tried
something similar for vim with 'share/vim/vimfiles' but it didn't
actually work for vim.

> Currently, we only have one such package, neovim-syntastic. I'd like to add
> more. Many plugins are compatible with both vim and nvim. However, they
> search for plugins at different paths. Therefore, the vim-syntastic and
> neovim-syntastic packages, which use the copy-build-system, differ only in
> the destination directories of the install-plan (and changing "Vim" to
> "Neovim" in the description).
> 
> My initial inclination is to remove the duplication of maintaining two
> install-plans (and other arguments) by creating a procedure that would take
> as input a Vim package that uses copy-build-system and output a Neovim
> package with the install-plan re-written.
> 
> Perhaps that solution would be overwrought. How would you recommend handling
> this situation?

My first idea would be to have the one package install the files into
both directories and combine them, but I feel like it falls apart when
it comes to searching for vim/neovim plugins and naming. One package
with two names? Call it vim-neovim-syntastic?

If vim/neovim move more apart and actually need separate plugins in the
future then I guess it would make more sense to have two actual packages
that can be installed by name (vim-foo and neovim-foo).

> [0] https://issues.guix.gnu.org/48112
> 
> Best,
> Jack


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Neovim plugin/addon packaging

[Jack Hill]

[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]

Thanks for your reply.

On Fri, 30 Apr 2021, Efraim Flashner wrote:

> On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote:
>> Greetings Guix,
>>
>> I'd like to improve the experience of installing Neovim plugins/add-ons with
>> Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so
>> nvim (the Neovim executable name) will be able to find plugins installed by
>> guix at …/share/nvim/site.
>
> I guess my first question is does it work? I think I first tried
> something similar for vim with 'share/vim/vimfiles' but it didn't
> actually work for vim.

Yes, it does work! I tested it with neovim-syntastic and a local 
neovim-fugitive package both with a guix environment and manually 
manipulated environment variables.

A difference between Neovim and Vim is that Neovim supports XDG_DATA_DIRS 
(and XDG_CONFIG_DIRS) as real search paths while the environment variables 
for Vim are single directories (compare `:help runtimepath` in the two 
editors).

>> Currently, we only have one such package, neovim-syntastic. I'd like to add
>> more. Many plugins are compatible with both vim and nvim. However, they
>> search for plugins at different paths. Therefore, the vim-syntastic and
>> neovim-syntastic packages, which use the copy-build-system, differ only in
>> the destination directories of the install-plan (and changing "Vim" to
>> "Neovim" in the description).
>>
>> My initial inclination is to remove the duplication of maintaining two
>> install-plans (and other arguments) by creating a procedure that would take
>> as input a Vim package that uses copy-build-system and output a Neovim
>> package with the install-plan re-written.
>>
>> Perhaps that solution would be overwrought. How would you recommend handling
>> this situation?
>
> My first idea would be to have the one package install the files into
> both directories and combine them, but I feel like it falls apart when
> it comes to searching for vim/neovim plugins and naming. One package
> with two names? Call it vim-neovim-syntastic?
>
> If vim/neovim move more apart and actually need separate plugins in the
> future then I guess it would make more sense to have two actual packages
> that can be installed by name (vim-foo and neovim-foo).

A combined package is an interesting suggestion. However, I share the 
concern about searching for packages. Having packages that are compatible 
with both editors use one naming scheme and ones that are compatible with 
only one use a different naming scheme seems like a implementation detail 
that would be better not to expose to me.

I drew inspiration for creating the Neovim package variants with a 
procedure from the package-for-python2 and sbcl-package->ecl-package. Of 
course those procedures have build system support and aren't depending on 
a common usage pattern of copy-build-system.

Is it time a a vim-build-system? Perhaps not, but I'm still not sure what 
the right way forward is.

Best,
Jack

Re: Neovim plugin/addon packaging

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]

On Sat, May 01, 2021 at 04:25:18PM -0400, Jack Hill wrote:
> Thanks for your reply.
> 
> On Fri, 30 Apr 2021, Efraim Flashner wrote:
> 
> > On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote:
> > > Greetings Guix,
> > > 
> > > I'd like to improve the experience of installing Neovim plugins/add-ons with
> > > Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so
> > > nvim (the Neovim executable name) will be able to find plugins installed by
> > > guix at …/share/nvim/site.
> > 
> > I guess my first question is does it work? I think I first tried
> > something similar for vim with 'share/vim/vimfiles' but it didn't
> > actually work for vim.
> 
> Yes, it does work! I tested it with neovim-syntastic and a local
> neovim-fugitive package both with a guix environment and manually
> manipulated environment variables.
> 
> A difference between Neovim and Vim is that Neovim supports XDG_DATA_DIRS
> (and XDG_CONFIG_DIRS) as real search paths while the environment variables
> for Vim are single directories (compare `:help runtimepath` in the two
> editors).
> 
> > > Currently, we only have one such package, neovim-syntastic. I'd like to add
> > > more. Many plugins are compatible with both vim and nvim. However, they
> > > search for plugins at different paths. Therefore, the vim-syntastic and
> > > neovim-syntastic packages, which use the copy-build-system, differ only in
> > > the destination directories of the install-plan (and changing "Vim" to
> > > "Neovim" in the description).
> > > 
> > > My initial inclination is to remove the duplication of maintaining two
> > > install-plans (and other arguments) by creating a procedure that would take
> > > as input a Vim package that uses copy-build-system and output a Neovim
> > > package with the install-plan re-written.
> > > 
> > > Perhaps that solution would be overwrought. How would you recommend handling
> > > this situation?
> > 
> > My first idea would be to have the one package install the files into
> > both directories and combine them, but I feel like it falls apart when
> > it comes to searching for vim/neovim plugins and naming. One package
> > with two names? Call it vim-neovim-syntastic?
> > 
> > If vim/neovim move more apart and actually need separate plugins in the
> > future then I guess it would make more sense to have two actual packages
> > that can be installed by name (vim-foo and neovim-foo).
> 
> A combined package is an interesting suggestion. However, I share the
> concern about searching for packages. Having packages that are compatible
> with both editors use one naming scheme and ones that are compatible with
> only one use a different naming scheme seems like a implementation detail
> that would be better not to expose to me.
> 
> I drew inspiration for creating the Neovim package variants with a procedure
> from the package-for-python2 and sbcl-package->ecl-package. Of course those
> procedures have build system support and aren't depending on a common usage
> pattern of copy-build-system.
> 
> Is it time a a vim-build-system? Perhaps not, but I'm still not sure what
> the right way forward is.

ng0/nikita thought about it a few years ago but I think the
copy-build-system works well enough. I know for vim we need a vim
profile hook to create the documentation, does neovim need something
like that too?


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Neovim plugin/addon packaging

[Jack Hill]

On Sun, 2 May 2021, Efraim Flashner wrote:

> ng0/nikita thought about it a few years ago but I think the
> copy-build-system works well enough. I know for vim we need a vim
> profile hook to create the documentation, does neovim need something
> like that too?

I'm not sure and will need to investigate. With the XDG_DATA_DIRS search 
path, if I install neovim and neovim-syntastic into the same environment, 
I am able to see references to the syntastic documentation in the main 
help index, but trying to navigate to them results in a 'E149: Sorry, no 
help for syntastic-checkers.txt' error, so clearly something is not quite 
right.

Best,
Jack

Re: Neovim plugin/addon packaging

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Mon, May 03, 2021 at 12:46:30AM -0400, Jack Hill wrote:
> On Sun, 2 May 2021, Efraim Flashner wrote:
> 
> > ng0/nikita thought about it a few years ago but I think the
> > copy-build-system works well enough. I know for vim we need a vim
> > profile hook to create the documentation, does neovim need something
> > like that too?
> 
> I'm not sure and will need to investigate. With the XDG_DATA_DIRS search
> path, if I install neovim and neovim-syntastic into the same environment, I
> am able to see references to the syntastic documentation in the main help
> index, but trying to navigate to them results in a 'E149: Sorry, no help for
> syntastic-checkers.txt' error, so clearly something is not quite right.
> 

That's always something we can fix later. It's also not more broken than
it is now.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]