Is there a stable branch for packaging?

[lelgenio]

Is there any branch in this repo that is protected from force-pushes?

Alternatively tags/releases could serve this purpose even better.

I ask so I can use it for reproducible builds for nixpkgs/NixOs, here is the package definition.

[aclist]

Thanks for asking. I could start doing releases. I'm currently using tags just for blobs.

I changed the branch structure yesterday as part of some long-overdue custodial changes:

main => contains latest stable branch dzgui => currently contains latest stable branch, is being kept for posterity purposes since most incoming links go to this branch (this is a remnant of from when DZGUI was a branch of DZTUI) dztui => formerly resided on main, moved and archived legacy DZTUI into this branch. DZTUI is considered out of development/deprecated now testing => for the latest bleeding edge/testing branch

The final step I plan to make here is rename the repo to dzgui, but this will break hardcoded links inside the turnkey install script that point back here, as well as the version checker/news ticker/etc. To mitigate this, I have cloned the repo to dzgui already (currently private) and will push a backend change to all dzgui-related branches that points the internal links to the new repo. This will take effect on all branches (main/dzgui/testing) so that no one is left behind. I will also update the relevant README files in this repo to link to the new repo should people still visit here via inbound links. I'll leave this repo as-is for some time (a few minor versions) to allow people to migrate, but should hopefully be a seamless process.

This is all just an artifact of DZGUI being merely a side-project of DZTUI at the time, so I didn't properly give it its own repo, but by that time, people were already finding this page, so I just went with it.

Regarding dependencies, I added support for Flatpak steam yesterday, although this is optional. (Uses Steam by default, but the user can opt to use Flatpak Steam if it is found during the dependency check.)

In answer to your original question, all branches are protected by default, and this project currently has no other contributors. I've only had one PR to date, approved manually. But I agree that tagged releases would be more straightforward and identifiable. I'm flexible in this regard, could set it up however you like.

[aclist]

Another note on optional dependencies: if the user optionally enables automod installation, xdotool is required. The application will warn about this.

[lelgenio]

The final step I plan to make here is rename the repo to dzgui, but this will break hardcoded links inside the turnkey install script that point back here, as well as the version checker/news ticker/etc. To mitigate this, I have cloned the repo to dzgui already (currently private) and will push a backend change to all dzgui-related branches that points the internal links to the new repo. This will take effect on all branches (main/dzgui/testing) so that no one is left behind. I will also update the relevant README files in this repo to link to the new repo should people still visit here via inbound links. I'll leave this repo as-is for some time (a few minor versions) to allow people to migrate, but should hopefully be a seamless process.

According to github's documentation this should not be a problem, links still work for as long as you don't create a new repo with the old name.

Regarding dependencies, I added support for Flatpak steam yesterday, although this is optional. (Uses Steam by default, but the user can opt to use Flatpak Steam if it is found during the dependency check.)

Perhaps I should remove steam as a hard dependency and let dzgui do it's thing.

In answer to your original question, all branches are protected by default, and this project currently has no other contributors. I've only had one PR to date, approved manually. But I agree that tagged releases would be more straightforward and identifiable. I'm flexible in this regard, could set it up however you like.

For now using the main branch should be enough as long as it's not overitten. Considering my goal of making it easy to run dzgui on with nix, it would be preferable to have a "stable" branch (in this case main) over releases. It would not be necessary to tell nix what the latest tag is, instead nix could just look for the latest commit of the stable branch.

I'll be making a pull request here soon to upstream that package definition.

Another note on optional dependencies: if the user optionally enables automod installation, xdotool is required. The application will warn about this.

I'll be adding xdotool as a hard dependency, since it's needed for a core functionality of the package and does not take up much storage to have installed.

I managed to enter a modded server without having xdotool installed, I did try(and fail) to enter that server from the official launcher before reading about dzgui, could it be that mods from the official launcher work for dzgui?

[aclist]

According to github's documentation this should not be a problem, links still work for as long as you don't create a new repo with the old name.

Interesting, did not know about the old inbound links redirecting. Still need to update internal links, though. For now there is no change; I'll let you know when this is happening.

Perhaps I should remove steam as a hard dependency and let dzgui do it's thing.

We merely check for the presence of Steam, flatpak Steam, or both, and if none are present, fail and warn, but we don't download anything for the user.

For now using the main branch should be enough as long as it's not overitten. Considering my goal of making it easy to run dzgui on with nix, it would be preferable to have a "stable" branch (in this case main) over releases. It would not be necessary to tell nix what the latest tag is, instead nix could just look for the latest commit of the stable branch. I'll be making a pull request here soon to upstream that package definition.

Yes, I saw that from the package file. I force pushed main just the one time to replace the DZTUI code with DZGUI, but it won't be happening again.

I'll be adding xdotool as a hard dependency, since it's needed for a core functionality of the package and does not take up much storage to have installed.

OK.

I managed to enter a modded server without having xdotool installed, I did try(and fail) to enter that server from the official launcher before reading about dzgui, could it be that mods from the official launcher work for dzgui?

xdotool is necessary if the user manually toggles automatic mod installation in the advanced options. This attempts to send a series of workshop download requests directly to the Steam developer console. It's not used under the normal (called "manual," but essentially guided downloads) mode.

We don't check pre-existing mods the first time DZGUI is run. But once you attempt to connect, we symlink all existing mods and prepare them for use, at which point any mods you had already will work. DZGUI does work with official and third party servers. It doesn't communicate with the official launcher itself at any point.

[aclist]

I've updated the docs to link back to your repo and also updated the online version at https://aclist.github.io/dzgui/dzgui.html