Add shebang support for PCK files

[Brogolem35]

Describe the project you are working on

Light weight application that uses Godot.

Describe the problem or limitation you are having in your project

Every Godot project must ship a nearly 60 MiB runtime, unless they create a custom one. 60 MiB is not big for a decently sized game, but is pretty hefty for an application.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding shebang support for Godot PCK files will allow them to be shipped seperetely from their runtime and will allow multiple Godot applications to use a common runtime. This may sound like not a big deal, especially for Windows users, but it is very useful for Linux users and distro maintainers, as most distros ship applications and their dependencies (libraries, frameworks, runtimes) seperately.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

#!/usr/bin/env -S godot --main-pack
binarybinarybinary

If this enhancement will not be used often, can it be worked around with a few lines of script?

Linux distros would need to ship a script along with the PCK file they ship, which may look something like this:

#!/bin/bash
exec godot --main-pack /usr/lib/foo.pck $SOME_FLAGS

If the application is not shipped by a distro maintainer, but is downloaded from the web, then the end user would need to do some manual work.

Is there a reason why this should be core and not an add-on in the asset library?

This changes how PCK files are handled by the engine/runtime and can not be done with an add-on.

[Calinou]

Is prepending a shebang to a binary file considered valid practice? It may cause some editors to recognize the file as text when it isn't.

It may be be a better idea to look into binfmt_misc instead (which is how you can run .exe directly on Linux without prepending wine, for instance).

For reusing Godot as a runtime, consider the Godot BaseApp on Flathub (which is used by Material Maker and Pixelorama): https://github.com/flathub/org.godotengine.godot.BaseApp

[bruvzg]

It should be possible to modify any existing PCK file without changing the engine to force it to use embedded PCK loading logic:

• Append size of original PCK (as 64-bit integer) to the end of file.
• Append 0x43504447 (PCK magic) to the end of file.
• Insert shebang at the beginning of file.
• Modify file_base (64-bit value at position 24 in the file, that is offset to the first stored file) to account for newly added shebang.

But PCK files are intended to be used with a specific version of the engine, and content usually is not fully compatible even for minor releases, so I'm not sure it's a good idea.

Is prepending a shebang to a binary file considered valid practice? It may cause some editors to recognize the file as text when it isn't.

I have seen a bunch of proprietary installers that doing it, sh script with appended binary.

[Brogolem35]

Is prepending a shebang to a binary file considered valid practice? It may cause some editors to recognize the file as text when it isn't.

I am not sure and I was hesitating to suggest this because of this. The reason I want a shebang instead of some other method is because it is easiest way to handle it, for developer, for distro maintainer, and for the end user. It is so easy that a user with below average knowledge can use it.

For reusing Godot as a runtime, consider the Godot BaseApp on Flathub (which is used by Material Maker and Pixelorama): https://github.com/flathub/org.godotengine.godot.BaseApp

Interesting. I didn't know about this. I will look into it.

It may be be a better idea to look into binfmt_misc instead (which is how you can run .exe directly on Linux without prepending wine, for instance).

I looked into the binfmt_misc after I saw your comment and this is the cleanest way I could do (uses systemd-binfmt.service because I am on Arch): Create script /bin/godot-runner:

#!/bin/sh
/usr/bin/godot --main-pack "$@"

Create file /etc/binfmt.d/Godot.conf:

:Godot:M::GDPC::/usr/bin/godot-runner:

Restart systemd-binfmt.service.

The reason why the godot-runner script is needed is because it seems that you can't pass arguments to interpreters with systemd-binfmt.service. I don't know if you can pass the --main-pack argument and get rid of the godot-runner with other methods.

[Calinou]

We could support using PCK files as positional argument to Godot, but doing the same for ZIP files (which is a valid main pack format) might be problematic for existing projects that may want to read a ZIP file as a positional argument for an use case other than a main pack.

This would also allow drag-and-dropping a PCK file onto a Godot executable and having it work.

[akien-mga]

Could you give some more details about your use case? Are you an application developer who expects that users of your application will have a compatible distro-packaged version of Godot in PATH? Or are you a distro packager trying to support multiple packaged apps from a shared runtime?

I've done the latter for a few years on Mageia and Fedora, with a /usr/bin/godot-runner export template, and wrapper scripts to run the applications with the --main-pack argument.

Using a shebang for binary/data files like this isn't something I've ever seen on Linux, so I'm not convinced about it being a good solution for the use case. If I double click a pck file, at most I'd expect it to be opened with my archiving tool, if some eventually get support for opening and extracting pck files.

Otherwise I agree with the solutions proposed by Calinou, for application developers I think targeting a flatpak runtime can be a better way to have multiple apps share a common runtime regardless of whether the distro provides the Godot version you need (see the wild span of Godot versions packaged by Linux distros currently, it's hard to ensure you'll have a compatible one and that it won't be named godot3 or godot4 instead of godot).

The binfmt_misc option also sounds interesting, and is something that distro packagers could set up themselves so that .pck files can be double clicked on their platform.

This still doesn't solve the fact that some pck files simply won't work with whatever Godot version is packaged, so overall I think there isn't any good solution aside from flatpaks / each distro packaging open source games for their current version of the Godot runtime.