Also build it with pythonInterpreters.pypy27_prebuilt instead of
python27, to avoid it being broken after #201859 is merged.
Keep in mind that the above change will make this derivation only work
with x86_64-linux for now (since pypy27_prebuilt is only packaged for
that platform). However support for newer platforms can be added later,
and a working package for one platform is better than a broken package
in 4 platforms.
This introduces a patch that improves binary reproducibility since changes in
ordering of the generated code indeed cause changes in the compiled code.
Additionally, since neovim embeds luajit-compiled bytecode into the nvim binary,
we are impacted by https://github.com/LuaJIT/LuaJIT/issues/626 . It is possible
to switch to lua 5.1, but that'd be a regression (luajit has much better
performance and some plugins depend on it, like for example Noice and Lazy).
Disabling `COMPILE_LUA` at build time would cause a runtime penalty each time
neovim starts. Instead, we run luagit with those security settings disabled for
the build-time code generation.
(Note to self: for a minimized testcase this seemed to help at
975ec13f5d5aefcac1dbb15fa867e660e07c93a1 but no longer at
03080b795aa3496ed62d4a0697c9f4767e7ca7e5 of luajit, which is surprising since
that commit doesn't look super relevant. _Also_ surprisingly it does seem to
work in the context of the neovim code generation, though, so that might be
good enough...)
Also, some of the code generation (using mpack and tables) still relies on
stable table ordering. This should eventually be fixed, but as a workaround
we use the luajit-with-stable-string-ids for those generators as well.
Fixes#207841
Without `--with-system-{ffi,expat}` flags, Python will use its own
embedded libraries that are out-of-date. Thanks to it, they can be a
security issue. So let's use our own libraries instead.
This is already what Python 3.x does, so should be safe.
