update.py and its companion update-shell.nix need to know where they are, else
they can't find the root default.nix of Nixpkgs. Because of this, I further
added a small piece of documentation about those path-dependent pieces of code.
nixpkgs creates a hierarchy of 3 folders share/runtime/<PKG_NAME> for no reason ?
makes debugging harder as well as paths longer when patching so this
removes this nested folders.
Now it's possible to use in an overlay `guiSupport` set to `false`
(boolean) and doing so will disable many X related dependencies from
being used and the closure would be reduced automatically - Close#116716.
`vimPackage` may not have a version attribute if it was specified using
a full name instead, such as with a `buildEnv` call. This can happen
right now on Darwin when `vimPackage` is `macvim.configure {…}`.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
In the current Vim, the Python support can be implemented by linking to
the Python library, e.g., lib/libpython3.8.dylib on darwin. The
previous workaround of wrapping Vim to prefix $PATH is not sufficient
anymore. Since in the current Vim, the Python interpreter is no longer
invoked, but instead, the dynamically linked library is used, in which
only the original Python modules are loaded, causing plugins to fail
to load their required Python modules.
Experiments show that, however, it is controlled by the $NIX_PYTHONPATH
environment variable. In this commit, we add the required environment
variable to the wrapped Vim workaround as previously proposed. So that
the Vim plugins can use Python modules in the specified Python derivation.
