"one file" builds - this gives us a single "gam" binary executable (gam.exe on Windows) with Python and all resultant libraries/packages/text files bundle into it.
"one directory" builds - this still gives us a gam binary executable but the file will be smaller and Python, libraries, text files will be stored in other folders.
GAM has used one file as far back as my memory serves because it's cleaner and easier to package but it comes at a big performance cost. On execution, "one file" builds need to decompress their Python libraries and text files to a temporary directory on the filesystem and run from there. This causes a significant delay when GAM is executad before GAM actually starts doing any real work. On a 2021 Macbook Pro (M1 CPU, 64gb RAM, 1tb SSD) one file takes about 7 seconds to run "gam version", "one directory" takes less than half a second to run the same command. That's an order of magnitude difference. Further, the extraction to a temp directory has caused various issues in the past. Some restrictive Linux systems don't let users write to their $TEMPDIR. As broken as that is they tend to first notice the behavior with GAM one file.
So yes, let's switch to one directory. A few notes:
"one directory" used to put all library files and directories in the same folder as gam / gam.exe making things really messy and confusing to admins who might look at the folder. Since PyInstaller 6.2 though there's been support for putting all these files in a sub-dir. GAM will put all these files in a lib/ sub-dir.
We need to account for all these extra files from "one directory" when packaging GAM (.zip, .tar.xz, .msi, etc). Windows MSI in particular will be uhh... fun...
It remains to be seen how Anti-Virus software that tends to see PyInstaller "one file" builds as viruses (AV vendor logic is, malware uses PyInstaller therefor all PyInstaller binaries are malware, real geniuses we've got there). Hopefully with things unpacked AV vendors won't be so suspicous.
When packaging and updating GAM there's a risk that some files in lib/ won't be overwritten OR lib/ files from an old GAM binary that don't exist in the new binary will remain. This may produce weird results and behavior we'll have to deal with as it arises. Just something to be aware of though.
GAM 7.00.03 pre-release will be first to use one directory on MacOS only. Future releases will implement it for Linux and (ugh, MSI) Windows.
PyInstaller supports two modes of operation:
"one file" builds - this gives us a single "gam" binary executable (gam.exe on Windows) with Python and all resultant libraries/packages/text files bundle into it.
"one directory" builds - this still gives us a gam binary executable but the file will be smaller and Python, libraries, text files will be stored in other folders.
GAM has used one file as far back as my memory serves because it's cleaner and easier to package but it comes at a big performance cost. On execution, "one file" builds need to decompress their Python libraries and text files to a temporary directory on the filesystem and run from there. This causes a significant delay when GAM is executad before GAM actually starts doing any real work. On a 2021 Macbook Pro (M1 CPU, 64gb RAM, 1tb SSD) one file takes about 7 seconds to run "gam version", "one directory" takes less than half a second to run the same command. That's an order of magnitude difference. Further, the extraction to a temp directory has caused various issues in the past. Some restrictive Linux systems don't let users write to their $TEMPDIR. As broken as that is they tend to first notice the behavior with GAM one file.
So yes, let's switch to one directory. A few notes:
"one directory" used to put all library files and directories in the same folder as gam / gam.exe making things really messy and confusing to admins who might look at the folder. Since PyInstaller 6.2 though there's been support for putting all these files in a sub-dir. GAM will put all these files in a lib/ sub-dir.
We need to account for all these extra files from "one directory" when packaging GAM (.zip, .tar.xz, .msi, etc). Windows MSI in particular will be uhh... fun...
It remains to be seen how Anti-Virus software that tends to see PyInstaller "one file" builds as viruses (AV vendor logic is, malware uses PyInstaller therefor all PyInstaller binaries are malware, real geniuses we've got there). Hopefully with things unpacked AV vendors won't be so suspicous.
When packaging and updating GAM there's a risk that some files in lib/ won't be overwritten OR lib/ files from an old GAM binary that don't exist in the new binary will remain. This may produce weird results and behavior we'll have to deal with as it arises. Just something to be aware of though.
GAM 7.00.03 pre-release will be first to use one directory on MacOS only. Future releases will implement it for Linux and (ugh, MSI) Windows.