Flatpak breaks post-processing scripts

[DrLex0]

Description of the bug

TL;DR: all but trivial post-processing scripts are fundamentally broken when running PrusaSlicer from Flatpak, and there is no sane workaround that I know of. This is problematic because Linux users are now pretty much forced to use Flatpak.

When configuring a post-processing script in the Linux Flatpak build of PS, it will be executed within the limited Flatpak container environment. If the script requires anything that is not present in that environment, it cannot run, no matter what the user has installed in their host OS.

For instance if the script uses basic Python, it will work because by pure luck, there happens to be a Python runtime installed inside the Flatpak. However, if it requires a specific Python package that is not in the Flatpak, it will fail. If Prusa decides to strip Python from the Flatpak at some point, it will fail. Similarly, if the script requires Perl, or some other binary or library not in the Flatpak, it will fail.

This screenshot is confusing, it does not mean that the configured script does not exist. It means that /usr/bin/perl as set in the script's shebang, does not exist inside the Flatpak environment.

I have already spent some hours on trying to work around this, and found 2 avenues to run things in or from the host environment, but both proved to be dead-ends.

Avenue 1:

sudo flatpak override --talk-name=org.freedesktop.Flatpak com.prusa3d.PrusaSlicer

and then invoke the post-processing script line in PrusaSlicer as:

flatpak-spawn --host /path/to/script

This fails because even though the script runs fine, it is given a path in the /tmp/ directory inside the Flatpak container as argument. Because the script runs in the host filesystem, it will not find any file at that location. I have found no way to detect this situation from within the script, or how to find the actual path of the file, if that is even possible at all.

Avenue 2:

sudo flatpak override --filesystem=host:ro com.prusa3d.PrusaSlicer
sudo flatpak override --env=LD_LIBRARY_PATH=/run/host/usr/lib64:/run/host/usr/lib com.prusa3d.PrusaSlicer

and possibly more custom environment variables into the Flatpak environment to work around the fact that the host filesystem will be mounted as /run/host/. For instance running pretty much any binary thing will require adding things to LD_LIBRARY_PATH, running Perl will also require hacking PERL5LIB…
When setting up all this voodoo just right, it becomes possible to invoke the mounted binaries by prepending /run/host/ to their absolute path.
However, it is obvious that this is total hell, configuring all those hacks cannot be expected from any regular user. And, even if it works, the script is still limited to modifying the G-code file. If it produces any extra files, those will be lost.

At this point I have no idea how to solve this or whether it can be solved at all. Maybe if there would be an option to only run the post-processing after the final G-code file has been saved in the host filesystem, then the flatpak-spawn --host option would work.

Project file & How to reproduce

Bogus-project-because-you-require-it.zip

How to reproduce:

1. Save this script somewhere and make it executable:

   #!/usr/bin/perl
   print "Hello world\n";
   

2. Configure the path to that script as post-processing script
3. Slice and export in a Linux Flatpak build of PrusaSlicer

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.9.0-linux, or any other Flatpak build of a previous version

Operating system

Any Linux

Printer model

Any printer

[neophyl]

Have you not seen the pinned issue at the top of this repo ? #13820

There have been several/many duplicates of issues regarding the access problems with flatpack. Enough to warrant the stickied post at the top.

[DrLex0]

@neophyl That pinned issue is of no help for this one at all. If you would read the whole text, you would see that I had already tried the ‘solutions’ proposed there, and why they don't work.