certain plugins need a custom configuration (available in passthru.initLua)
to work with nix. For instance unicode-vim needs to configure where to
find the data:
```
vim.g.Unicode_data_directory="${self.unicode-vim}/autoload/unicode"
```
if true, the wrapper automatically appends those snippets when necessary
first appearance of initLua in https://github.com/NixOS/nixpkgs/issues/352741
This will make testing those plugins easier.
Fixing this warning from checkhealth
provider.ruby: require("provider.ruby.health").check()
Ruby provider (optional) ~
- Ruby: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
- Host: /nix/store/l354hgiahcjd81qazlc870104i26lm9b-neovim-0.10.2birdeevim/bin/birdeeVim-ruby
- OK Latest "neovim" gem is installed: /home/birdee/.local/share/gem/ruby/3.3.0/gems/neovim-0.10.0/lib/neovim/connection.rb:1: warning: logger was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add logger to your Gemfile or gemspec to silence this warning.
0.10.0
steps taken:
added `gem 'logger'` to Gemfile
ran the following on the directory
nix run --no-write-lock-file github:BirdeeHub/neovim_ruby_updater
add a checkPhase (if doCheck == true, disabled by default) that tries to
start neovim and fails in case of errors. It allows to catch small
misconfiugurations before switching to a new config.
neovim: fix regression about nodeJs / withRuby
in the last neovim refactor, there was a regression regarding
withNodeJs / withRuby handling, particulary not adding nodejs anymore to
the PATH
fix https://github.com/NixOS/nixpkgs/issues/349496
it is relatively cumbersome to generate the vim package from the list of plugins so expose it so users can generate their own packpathdirs for an unwrapped neovim. I've tested this change with an upcoming home-manager change that makes neovim configuration more standard in the home-manager context
Now that we have structured attributes enabled, it's easier than ever to
access the wrapper config from itself. Let's expose the 'plugins'
derivations instead of the final 'packpathDir' with which one can't do much.
TLDR: the neovim wrapper accepts a list of neovim derivations in
`plugins` instead of the symlinkJoin of plugins in `packpathDir`.
With exposed plugins, one could tweak the current wrapper with more
plugins, e.g. neovim.withPlugins([fugitive]).withPlugins([plenary]) .
we could also add a boolean to autoadd the plugins passthru.initLua,
better handle the dependencies (runtime programs, python deps).
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
- factorize the export HOME in runTest
- adjust suffix for nvim-with-luasnip (it was misleading)
- make 'checkAliases' check for executable bit as well
- expose nmt because it's more convenient to find its store path
* buildNeovimPlugin: pass a derivation to luaAttr
and deprecate passing a string.
Passing a string is not a typical/good nixpkgs habit. We want to give more control on
which attribute to wrap, without having to add it to the lua package set
necessarily.
* vimPlugins: update plugin with new syntax
buildNeovimPlugin now accepts derivations instead of the lua package name. This PR reflects the change
* nickel: switch to cargoHash
* gnvim-unwrapped: switch to cargoHash
* surrealdb-migrations: switch to cargoHash
* wluma: switch to cargoHash
* httm: switch to cargoHash
No need (observed) for these packages to have a vendor Cargo.lock. If they for some reason have to use a different Cargo.lock than upstream, they should copy that to the build directory as well, otherwise the build will fail. They don't, so I infer there's no reason to use Cargo.lock.
As described in https://github.com/NixOS/nixpkgs/issues/318925, lua
neovim plugin dependencies are not visible from neovim.
This calls the lua hook on the neovim packpack dir with the plugins.
The hook scans the propagated-build-input files (generated via
neovimUtils.packDir) and adds them to LUA_PATH / LUA_CPATH when
necessary.
We then wrap neovim with these values LUA_PATH prefixed with those
values
in order for neovim to catch plugins dependencies, we fork
vimUtils.packDir as `neovimUtils.packDir` to merge the various plugins
nix-support/propagated-build-inputs files in the packDir derivation
$out/nix-support/propagated-build-inputs where there was previously
none.
Having a fork allows us to experiment without impacting vim plugins.
Once we are more confident this doesn't break stuff and/or the
implementation is final, we can merge the fork back or replace one by
the other.
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
- merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git.
- remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required.
- fixes https://github.com/NixOS/nixpkgs/issues/166205
- provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548https://github.com/NixOS/nix/issues/9640
- pkgsCross.x86_64-freebsd builds work again
This change can be represented in 3 stages
1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi}
2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin}
3. remove all references to libcxxabi outside of llvm (about 58 packages modified)
### merging libcxxabi into libcxx
- take the union of the libcxxabi and libcxx cmake flags
- eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency
- libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx.
- darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient.
- linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient.
- libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+)
- git/libcxx/defaul.nix does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway.
### stdenv changes
- darwin bootstrap, remove references to libcxxabi and cxxabi
- cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12)
- adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx
### 58 package updates
- remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed
- swift, nodejs_v8 remove libcxxabi references in the clang override
https://github.com/NixOS/nixpkgs/pull/292043
