Pull in the patch from the submitted pull request to upstream to fix the
unit test data that doesn't tolerate floating point approximation.
- Unbreaks aarch64-linux
- Fixes the build for aarch64-darwin
To avoid duplicating the ruby compilation code, this change exposes two
functions `mkRubyVersion` and `mkRuby`, which can be used in an overlay
to build any past or current ruby version.
An example overlay:
```nix
self: super:
{
ruby_2_7_6 = super.mkRuby {
version = super.mkRubyVersion "2" "7" "6" "";
sha256 = "042xrdk7hsv4072bayz3f8ffqh61i8zlhvck10nfshllq063n877";
};
ruby_3_1_2 = super.mkRuby {
version = super.mkRubyVersion "3" "1" "2" "";
sha256 = "0gm84ipk6mrfw94852w5h7xxk2lqrxjbnlwb88svf0lz70933131";
};
}
```
PR #177891 tried fixing a problem with `buildDhallUrl` in environments
where proxy variables are necessary for internet access to work. The
`impureEnvVars` should be set in `downloadEncodedFile` instead of the
final `runCommand`, as the former is an FOD, the latter isn't.
Neovim plugins are now more often than not written in lua.
One advantage of the lua ecosystem over vim's is the existence of
luarocks and the rockspec format, which allows to specify a package
dependencies formally.
I would like more neovim plugins to have a formal description,
"rockspec" being the current candidate.
This MR allows to use nix lua packages as neovim plugins, so as to enjoy
every benefit that rockspecs bring:
- dependdency discovery
- ability to run test suite
- luarocks versioning
- rockspec metadata
the vim update.py script will check if an attribute with the vim plugin
pname exists in lua51Packages. If it does, it uses
buildNeovimPluginFrom2Nix on it, which modifies the luarocks config to
do an almost flat install (luarocks will install the package in the lua
folder instead of share/5.1/lua etc).
It also calls toVimPlugin on it to get all the vim plugin niceties.
The list of packages that could benefit from this is available at
https://luarocks.org/labels/neovim
but I hope it grows.
The PEP600 standard gives Python's naming scheme for various
architectures; it follows the convention which was in use by Fedora in
2014. According to PEP600, the architecture name for Power PC is
`ppc64le`, not `powerpc64le`. This is also how python3 declares its
"supported wheels" under Debian on PowerPC, as checked with `pip debug
--verbose`
$ pip debug --verbose | grep powerpc
$ pip debug --verbose | grep ppc | head
cp39-cp39-manylinux_2_31_ppc64le
cp39-cp39-manylinux_2_30_ppc64le
cp39-cp39-manylinux_2_29_ppc64le
cp39-cp39-manylinux_2_28_ppc64le
cp39-cp39-manylinux_2_27_ppc64le
cp39-cp39-manylinux_2_26_ppc64le
cp39-cp39-manylinux_2_25_ppc64le
cp39-cp39-manylinux_2_24_ppc64le
cp39-cp39-manylinux_2_23_ppc64le
Let's adjust the `pythonHostPlatform` expression in
cpython/default.nix to pass the architecture using the naming scheme
Python expects.
Verified on a Raptor Computing Systems Talos II. Without this commit,
PyQt5 fails to build, failing with "unsupported wheel". With this
commit, it builds successfully.
