It was previously referencing `$bin`, but this package no longer produces a
`bin` output, just `out` and `share`. Updated to make the comparison check a bit
more robust.
Also updated to avoid direct dependency on the `$src` directory out of the nix
store, instead using the processed src setup in the unpackPhase. This provides a
cleaner abstraction between the build/install phase and the input src phase, and
avoids an unnecessary dependency on whether the source disted tarball comes from
`fetchFromGitHub` (in which case it's an unpacked directory) or something like
`fetchurl`. In either case, stdenv is responsible for processing the input `src`
and setting up a clean build dir for us, so we should use that.
This produces an equivalent directory tree, except that the vim plugin is no
longer broken.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
(cherry picked from commit dadc7eb329)
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
The fzf vim plugin wasn't working because it was making a symlink to a
directory with the full source code. This directory isn't present
anymore since the commit e95f17e272 wich
removes it because it isn't so useful for the go packages.
I fixed it by manually copying the plugin/ directory into the out
derivation, which is the only part of the source that contains the vim
plugin.
During patch phase, the path to the fzf binary is overwritten in the vim
plugin source. The sed expression doing this wasn't working because the fzf
code changed in this commit:
02ceae15a2
making the patch useless.
I fixed it and added a check to verify that the plugin was effecively
patched to prevent this to happen in the future.
So that helper scripts can be easily sourced in interactive shell
configuration. `autojump` package was already present and had the same
requirements for findind a `share` folders, so I took an inspiration
there.
I beleive this is a better alternative to:
- https://github.com/NixOS/nixpkgs/pull/25080
- https://github.com/NixOS/nixpkgs/pull/27058
Replacing `$out/share/shell` with `$bin/share/fzf` was necessary to
prevent dependency loop in produced derivations.
zowoq