The current algorithm creates attributes with null values for packages
with no source in a variant of MELPA. Though will satify dependencies
they produce no files, and though a build that transitively depends on
one them will be successful, Emacs won't find them and any code
depending on them won't work.
The solution with minimal code change would have been filtering the
list of results from melpaDerivation by comparing the value against
null, but that leads to an infinite recursion.
This commit also moves legacy renames from the shared to the unstable
set, as the corresponding null value elements won't exist in the
stable set anymore.
The test used for the problem was:
$ nix-build --show-trace ./default.nix -A emacs26Packages.melpaStablePackages.findr
error: expression does not evaluate to a derivation (or a set or list of those)
The expected output, obtained with this commit is:
$ nix-build --show-trace ./default.nix -A emacs26Packages.melpaStablePackages.findr
error: attribute 'findr' in selection path 'emacs26Packages.melpaStablePackages.findr' not found
According to https://repology.org/repository/nix_unstable/problems, we have a
lot of packages that have http links that redirect to https as their homepage.
This commit updates all these packages to use the https links as their
homepage.
The following script was used to make these updates:
```
curl https://repology.org/api/v1/repository/nix_unstable/problems \
| jq '.[] | .problem' -r \
| rg 'Homepage link "(.+)" is a permanent redirect to "(.+)" and should be updated' --replace 's@$1@$2@' \
| sort | uniq > script.sed
find -name '*.nix' | xargs -P4 -- sed -f script.sed -i
```
The `seq` package that comes with emacs 27 is newer than that provided
by ELPA. Various packages list `seq` as an input, causing it to be
imported from ELPA in addition to the (newer) version bundled with
emacs. Relying on the version packaged with emacs resolves the
conflict.
Fixes#73346
I suspect there is something wrong with the elpa package generator. Emacs'
setup-hook adds the `site-lisp` directory to `load-path`, but elpa packages end
up having their code in `site-lisp/elpa/package-version, and thus emacs cannot
load them.
If that worked, adding `color-theme` as `builInput` might be better than
explicitly adding its `site-lisp` to the `load-path` in the `buildPhase`
Before this patch, the stable version did not run configure, and the
unstable version added `openssl` and `pkgconfig` to
dependencies.
Also, `dontConfigure = true` seems more readable than `configureScript
= "true"`.
We need both the .so as well as the proper autoloaders that are generated when
we build an emacs package, so we cannot use the normal stdenv.mkDerivation but
have to inject the building of the libraries instead.
Also, use the proper libvterm-neovim we have in nixpkgs instead of vendoring it.
