-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes for flatpak and other restricted environments (Linux) #2372
base: Dev
Are you sure you want to change the base?
Conversation
Flatpak build env doesn't have internet access.
For writing settings.sav and presets.sav
Also, here is a compare without renaming |
Could I request the label Component: Cosmetics as well? Most of the Python changes are specifically on custom cosmetics code. |
# Conflicts: # Patches.py
Okay, I think this is good for review now. I did have Dusk give the Flatpak a try, and seemed to patch models fine, and I've tested custom music. I'm going to upload a version of the Flatpak to the dev channel as well so I can link it here for more testing, though building for yourself should also work. Some testing should also be done with the branch and release build of it in a normal circumstance to make sure behaviour hasn't changed. I tried hard to make sure it wouldn't, but you never know. I was able to cross-compile an AARCH64 version of the Compress executable, but my distro doesn't have packages for 32-bit ARM so someone else will have to get that if it seems necessary. Flathub itself will only create x86_64 and AARCH64 packages. I can also change to the other branch without the renames adding |
accept cwd for run_process
This PR adds support for running the randomizer in environments where the app directory itself is not writable. My personal motivation behind this was to let the randomizer run in a flatpak environment, however as I worked on this I realized it also helps resolve installing the randomizer in say
/usr/local/bin
or:\Program Files
as well, although I've only made changes necessary for Linux environments currently. Windows should be handled by someone who actually uses the platform, possibly with an eye to also create a store package.Changes:
local_path
anddata_path
functions to make it clear they should only be used for reading files, not writing.package-lock.json
. This hasn't been updated since 7.1, but the tool Flatpak provides for downloading node modules as sources prior to entering the build environment works off of this, and if the output from thepackage-lock.json
does not exactly match what thepackage.json
needs in the build environment, issues arise.settings.sav
is read and written atXDG_CONFIG_HOME
if the app directory is not writable.XDG_DATA_HOME/Output
if the app directory is not writableARCHIVE.bin
file fromXDG_CACHE_HOME
if the app directory is not writable.Flatpak and Flathub
With these changes it is now possible to build a Flatpak for OoTR, so long as it is using this branch as its git source for now. I have created a repository with all the files needed to do so. If you wish to give it a try yourself, you should install Flatpak, the Flathub repository (tutorial for building has you install it user-wide, not sure if issues arise with a globally configured one, but you can have both installed at the same time) and the Flatpak building tools. I found all of these available from my package manager. If further help finding them is needed I can do so.
To build and install the Flatpak in that repository, run
flatpak-builder --force-clean --user --install-deps-from=flathub --repo=repo --install builddir com.ootrandomizer.electrongui.yml
then to run the Flatpak runflatpak run com.ootrandomizer.electrongui
. It is also possible to create a file to share with other users if desired.While that repository has the basics, we should decide if we want to distribute the Flatpak on ootrandomizer.com, or if we should submit the package to Flathub in which case there is still more required work to do. Other adjustments can be made as desired too.