Build another AppImage with all popular dependencies

Issue Description

Currently, the Vim AppImage distributed by the vim/vim-appimage repository does not include some popular dynamic libraries, such as libperlX, libpython2.7, libpython3X, liblua5X, and librubyX. While the current approach of not including these libraries keeps the size of the AppImage small, it also makes it difficult to use some Vim plugins and scripts that require these dependencies.

Therefore, we would like to request a new Vim AppImage that includes all popular dependencies by default. This would allow users to have a more seamless experience when using Vim with plugins and scripts that require these dependencies.

Feature Request Details

• Include libperlX, libpython2.7, libpython3X, liblua5X, and librubyX in the Vim AppImage (in the tremendous build).
• Ensure that the AppImage works on various Linux distributions and architectures.
• Update the documentation to reflect the changes made.

Proposed Solution

We propose creating a new Vim AppImage that includes all popular dependencies (in the tremendous build). This can be achieved by modifying the current recipe file and build scripts to include these dependencies during the build process. We also suggest performing thorough testing on various Linux distributions and architectures to ensure that the AppImage works as expected.

Additional Context

The current Vim AppImage is a great tool for providing a portable version of Vim without the need for installation or dependencies. However, having another version that includes all popular dependencies by default would provide an even better user experience and make it easier to use Vim with a wider range of plugins and scripts.

Thank you for considering our feature request.

[chrisbra]

hm,
I am not found of building yet another appimage. This would possibly mean, to create one GVim and Vim Appimage. And I suspect we will run into a lot of issues similar to #48 just because we are either missing to bundle some dependent libraries or the bundled libraries cause some issues with the host-system.

Can't you simply make use of 'perldll', 'pythondll', 'python3dll' and 'luadll' ?

[chrisbra]

I'll have a look, but as mentioned this will most likely be a rabbit-hole with either missing libraries (e.g. when trying to import python modules that are C-based) or might even crash.

[ychin]

Can't you simply make use of 'perldll', 'pythondll', 'python3dll' and 'luadll' ?

Actually, only Python 2/3 are dynamic right now. They are only dynamic implicitly because the configure rules use dynamic builds when you try to enable both python2 and 3 . I think build_vim.sh probably should be using =dynamic for all the scripting interfaces so that they aren't trying to pull in some static .so files from fixed locations.

Python 3 could also probably use stable ABI with a --with-python3-stable-abi=3.8 flag since that's supported now.

[TheDreadedAndy]

Is it still the case that these libraries aren't supposed to be shipped? The latest AppImage (9.1.0071) seems to include lua, python2, ruby, and perl in its library folder.

The situation is worse for the GVim appimage, which significantly increased in size after the v9.0.1899 build.