hum I guess I can still improve things to run more tests:

[==========] 3902 tests from 328 test files ran. (145522.45 ms total)
[  PASSED  ] 3882 tests.
[ SKIPPED  ] 20 tests, listed below:
[ SKIPPED  ] test/functional/api/server_requests_spec.lua @ 148: server -> client requests and notifications interleaved will close connection if not properly synchronized
[ SKIPPED  ] test/functional/api/server_requests_spec.lua @ 326: server -> client connecting to another (peer) nvim via ipv6 address
test/functional/api/server_requests_spec.lua:331: no ipv6 stack
[ SKIPPED  ] test/functional/core/channels_spec.lua @ 31: channels can connect to socket
[ SKIPPED  ] test/functional/core/job_spec.lua @ 729: jobs exit event follows stdout, stderr
[ SKIPPED  ] test/functional/eval/backtick_expansion_spec.lua @ 39: backtick expansion with shell=fish
test/functional/eval/backtick_expansion_spec.lua:41: missing "fish" command
[ SKIPPED  ] test/functional/eval/interrupt_spec.lua @ 16: List support code does not actually allows interrupting with just got_int
[ SKIPPED  ] test/functional/lua/treesitter_spec.lua @ 33: treesitter API with C parser works
test/functional/lua/treesitter_spec.lua:33: TREE_SITTER_PATH not set, skipping treesitter parser tests
[ SKIPPED  ] test/functional/normal/langmap_spec.lua @ 243: 'langmap' Translates modified keys correctly
[ SKIPPED  ] test/functional/normal/langmap_spec.lua @ 249: 'langmap' handles multi-byte characters
[ SKIPPED  ] test/functional/normal/langmap_spec.lua @ 259: 'langmap' handles multibyte mappings
[ SKIPPED  ] test/functional/options/keymap_spec.lua @ 190: 'keymap' / :lmap mappings not applied to macro replay of :lnoremap
[ SKIPPED  ] test/functional/plugin/lsp/lsp_spec.lua @ 462: Language Client API basic_init test should check the body and didChange incremental
[ SKIPPED  ] test/functional/plugin/lsp/lsp_spec.lua @ 510: Language Client API basic_init test should check the body and didChange incremental normal mode editting
[ SKIPPED  ] test/functional/provider/nodejs_spec.lua @ 12: Missing nodejs host, or nodejs version is too old.
[ SKIPPED  ] test/functional/provider/python3_spec.lua @ 19: Python 3 (or the pynvim module) is broken/missing
[ SKIPPED  ] test/functional/provider/python_spec.lua @ 27: Python 2 (or the pynvim module) is broken/missing
[ SKIPPED  ] test/functional/provider/ruby_spec.lua @ 27: Missing neovim RubyGem.
[ SKIPPED  ] test/functional/terminal/tui_spec.lua @ 1329: TUI 't_Co' (terminal colors) TERM=interix uses 8 colors
[ SKIPPED  ] test/functional/ui/float_spec.lua @ 1389: floatwin with ext_multigrid supports second UI without multigrid
[ SKIPPED  ] test/functional/ui/messages_spec.lua @ 1050: ui/msg_puts_printf output multibyte characters correctly
test/functional/ui/messages_spec.lua:1068: Locale ja_JP.UTF-8 not supported

@GrahamcOfBorg build neovim-unwrapped

cc @timokau

As I said in my email, I don't really understand why this is necessary (what are the advantages over your own shell.nix or just adding these packages to your system?).

This is the question why I requested external review. I believe its is worthwhile because neovim is popular enough that people may want to contribute. The dependencies to hack on neovim are neither obvious or well documented so instead of having everyone tweaking his own shell.nix, I thought I could share the changes. It's only because of this specificity that I believe it's worthwhile to have in nixpkgs. Also the complexity is low. But yeah it still is more complex than the current one so I could understand not wanting that in. I do help maintaining (the) neovim (package) if that can help with my case :)

@teto maybe it'll be more appropriate to share your Neovim's shell.nix in the WiKi? Then perhaps it'll be nice to see a link to it in the derivation. But I tend to think that Nixpkgs should target users and not developers, with all due respect :). What bothers me is that this PR doesn't make it completely trivial to setup a shell.nix for Neovim development, and a complete shell.nic is still required for someone to either write themselves or copy. Hence I tend to think it's worth to putting all of this information in 1 place and not make the derivation more complex then it is.

no you are right, I will post this either in neovim wiki or in some neovim flake. Yet another repo to maintain :'(
I've modified the spirit of the PR to just test more in the make functionaltest call. This is not enabled by default so the close size isn't changed.

As I said in my email, I don't really understand why this is necessary (what are the advantages over your own shell.nix or just adding these packages to your system?).

This is the question why I requested external review. I believe its is worthwhile because neovim is popular enough that people may want to contribute.

I'm not fully opposed to have dev-setup related things in nixpkgs, but @doronbehar's concerns are warranted. We'd probably have to think about how to do this right and in a uniform manner if we wanted to do it.

The dependencies to hack on neovim are neither obvious or well documented so instead of having everyone tweaking his own shell.nix, I thought I could share the changes.

That sound like you need better upstream documentation ;)

It's only because of this specificity that I believe it's worthwhile to have in nixpkgs. Also the complexity is low. But yeah it still is more complex than the current one so I could understand not wanting that in. I do help maintaining (the) neovim (package) if that can help with my case :)

Yeah I agree with the low complexity, so the benefit doesn't have to be that great to be worthwhile. In my opinion you, a neovim and nixpkgs core contributor, thinking its a good idea is sufficient. So if you really would prefer this in nixpkgs, I'm not opposed.