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.
Because the configure script hasn't been update to work with Python 3.10
and never will. Spidermonkey 78 is EOL.
Traceback (most recent call last):
File "/build/firefox-78.15.0/obj/../js/src/../../configure.py", line 25, in <module>
from mozbuild.configure import (
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/configure/__init__.py", line 33, in <module>
from mozbuild.util import (
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/util.py", line 760, in <module>
class HierarchicalStringList(object):
File "/build/firefox-78.15.0/python/mozbuild/mozbuild/util.py", line 785, in HierarchicalStringList
class StringListAdaptor(collections.Sequence):
AttributeError: module 'collections' has no attribute 'Sequence'
Every package should have a maintainer and we should not throw it away if we arleady have one.
Also in reality the maintainer of python3 is also the one of python3-minimal
Alternative malloc implementations in ruby are not fully encapsulated.
Their header files are required when building gems with native
extensions, like bcrypt.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ../common/ipp.o:(.bss+0x0): multiple definition of `lpath'; tglobals.o:(.bss+0x30): first defined here
