hytale-launcher: init at 2026.03.03-a4f6003

[karol-broda]

adds the official hytale launcher, a game launcher for hytale - an upcoming block-based game from hypixel studios.

the package fetches the prebuilt linux binary and patches it with autoPatchelfHook for nixos compatibility

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[andreashgk]

Unless there is a way to prevent the auto-updating behaviour for this launcher this package is flawed. It appears like the hytale launcher will try to replace its own binary when there is a launcher update, which is not possible when it is in the nix store. Either this has to be fixed or there needs to be a way to disable auto updating (haven't seen any info regarding this yet). If this is not fixed the package will likely break a lot.

Also, its probably worth waiting for the game to come out in the first place to see if it doesnt need any extra dependencies like java for instance.

[karol-broda]

Unless there is a way to prevent the auto-updating behaviour for this launcher this package is flawed. It appears like the hytale launcher will try to replace its own binary when there is a launcher update, which is not possible when it is in the nix store. Either this has to be fixed or there needs to be a way to disable auto updating (haven't seen any info regarding this yet). If this is not fixed the package will likely break a lot.

Also, its probably worth waiting for the game to come out in the first place to see if it doesnt need any extra dependencies like java for instance.

for me it is already disabled

[gepbird]

At the end, please squash your commits for the package, you should have:

• maintainers: add karol-broda
• hytale-launcher: init at 2026.01.12.e43ec47

Let's hope it will still work after the next update from upstream :)

Where did you get this source from? From https://hytale.com/download clicking on linux gives me a flatpak and not the zip. An update script that scrapes the website for the latest version would be nice.

[jelni]

Where did you get this source from?

@gepbird the launcher contacts https://launcher.hytale.com/version/release/launcher.json to fetch its updates, which could be used for an update script

[karol-broda]

btw if this wont get merged before the release you can just do this, this worked for me:
https://gist.github.com/karol-broda/e777b502db6f6e066fd1c1e8596b5736

maybe copy the file from this pr instead of from the gist idk

[gepbird]

Considering the Nix expression for the current release of the launcher, I'd merge this as it is now.
But probably it will require more dependencies after it can launch the actual game and the package has to be changed, and I'm not entirely sure if auto updates will break the launcher.

I think a fair decision could be waiting out the remaining 6 hours, making sure the package can launch the game and then merge it. I don't want to delay it by waiting for the next release to check if auto update doesn't break the launcher as many of us are excited to play it :)

btw if this wont get merged before the release you can just do this, this worked for me: https://gist.github.com/karol-broda/e777b502db6f6e066fd1c1e8596b5736

maybe copy the file from this pr instead of from the gist idk

Alternatively if you're using flakes, this is also an option.

[andreashgk]

nix-alien also works fine to launch the launcher currently and that method does not fail to auto-update
im not sure how you disabled auto updates, there is no option for it as far as im aware and this package broke for me because of an update

[karol-broda]

yea waiting until release makes sense, ngl just so hyped to finally play this

[karol-broda]

nix-alien also works fine to launch the launcher currently and that method does not fail to auto-update im not sure how you disabled auto updates, there is no option for it as far as im aware and this package broke for me because of an update

for the auto update i read some of the files that were generated in .local and searched .config a bit if it maybe set a config, because it was set by default for me, will look into it a bit later

[gepbird]

nix-alien also works fine to launch the launcher currently and that method does not fail to auto-update im not sure how you disabled auto updates, there is no option for it as far as im aware and this package broke for me because of an update

That seems like a cool tool, but I just tried it with and without nixGL and got a gray window at the end.

The flatpak has worked for me without issues.

[glabrie]

I don't know how much it will help, but I have asked on Twitter if they could add an option to download old builds. I imagine that would be the best case scenario for the problem!
https://x.com/ghil_labrie/status/2034965694287098345?s=20

[ikcii]

If that's possible that'd be a good solution. I don't know if a derivation that fetches the hash can exist tho because that hash changes from time to time and therefore the derivation fetching it would have its own hash change from time to time which would make it non-reproducible again. Or the version of the launcher the hash is calculated from has to be pinned in which case we have the same problem as before again.

Then again maybe I'm just not deep enough in the inner workings of nix so there might be a way to do that.

It'd have to be impure. The best solution would be to do our best to ensure the package for Hytale launcher is robust enough that we can confidently automate updates when they appear via CI/CD, or have the Hytale devs keep direct URLs to older versions of the launcher still accessible after an update happens. I suppose the best way would be to automate downloading and unpacking the official Flatpak release, then just bumping the hash automatically whenever it changes and making use of the fact that Flatpaks have a standarized structure which should result in updates being smooth but like I mentioned earlier, this is still going to make every Nix build with older versions of Hytale always fail unless we either get a permission to redistribute the launcher binaries in the cache or get the devs to host old launcher builds.

[GetPsyched]

Hello! Apologies for the noise, but could someone rebase the PR again? It breaks since #494416 landed in nixos-unstable.

[rostby]

Are we gonna get GTA 6 before hytale-launcher in nixpkgs?

[Ben9986]

Are we gonna get GTA 6 before hytale-launcher in nixpkgs?

As far as a know/recall, the main blocker is that Hytale does not keep old versions of the launcher available when they release a new one. Because we are also not allowed to redistribute the launcher binary, this means that people with this package installed would not be able to update/install their systems when a new version is released until the update propagates through to their nixpkgs branch. They would be met with a HTML 404 error when nix tries to download the launcher from the hytale site.

I'm no nixpkgs expert so I'm not sure if there is any way for us to release this package as it stands without frequently breaking people's systems, or allowing runtime downloads (not sure if these are allowed on nixpkgs, or would work considering the nix store is read only). Hytale could update the launcher multiple times in a week and this would leave people unable to update their systems (unless they remove the hytale-launcher package, which is inconvenient).

So, as far as I see it, the main solutions are:

1. The Hytale devs keep the previous few versions of the launcher available for us to download from their servers, which would give us time to update our package before rebuilds stop working, and/or,
2. The Hytale devs allow slightly older versions of the launcher to run and launch the game i.e. they would allow launchers 2-3 weeks out of date to still launch the game, even in offline only mode would be acceptable to me. As it stands, I believe the launcher breaks when it sees there is an update available and it cannot update itself due to it being in the read-only nix store (someone correct me if I'm wrong) and,
3. They use a license for the Hytale launcher which allows us to redistribute the unmodified binary. This would allow us to change the licence from unfree and be able to cache the build, but would not fix the issue of the launcher breaking when it tries to update itself and fails.

Options 1 & 2 would both have to be implemented together, or options 2 & 3 together.

Someone let me know if any of this is incorrect, I didn't fancy going back through the 150 comments of this pull so I'm going off my memory, which is often flawed :).

[liquidnya]

Someone let me know if any of this is incorrect, I didn't fancy going back through the 150 comments of this pull so I'm going off my memory, which is often flawed :).

I like how you summarized the options 1, 2, and 3 to add more structure to this conversation.

I want to add the following as well:

• option 4) @ItsLiyua is suggesting the following here:

  In my opinion downloading the launcher at runtime would be fine as well. It'll update the game impurely anyway and the devices that have hytale installed are usually not the ones that need to be 100% reproducible

  This could also be a solution that would be very differently. This would be a hytale-launcher-launcher in a way, downloading the launcher at runtime and then starting it. This would not do any hash verification during built-time.

  @ItsLiyua's comment has 5 👍 and 0 👎 as of the time this message was posted.
  However, @jjsuperpower suggested this idea earlier and as of now that comment has 0 👍 and 9 👎.
  To me that sounds like it might be a compromise that is not wanted, but better than having no option.

  How the at runtime downloaded hytale-launcher is trusted is to be defined. E.g. by trusting cacert and the domain name offering the download or maybe the certificate is presented to the user and the user is making the choice. Additionally the hash of the last known launcher could be added to the package for skipping runtime validation if it is the same launcher; see this comment.

• option 5) I (@liquidnya) am suggesting the following here:

  [...] That way the hytale-launcher package would work out of the box and is not dependent on when it is build, while still allowing users to add the launcher during build (they could even override the src and add the launcher from a folder on their system to bootstrap the launcher).

  This option basically gives users the possibility to create their own hytale-launcher package and they provide the launcher executable and they manage it themselves. For example pkgs.mkHytaleLauncher { src = ./some/folder/hytale-launcher }. However, they would need to make sure to not commit the launcher into their repositories.
  This way an older configuration could still build.

  Furthermore, the package could provide tools (bash scripts) to update the hytale-launcher easily.

Option 4 could be implemented on its own.
Option 5 could be implemented on its own, added to any other options or it could just be pkgs.hytale-launcher.overrideAttrs { src = ./some/folder/hytale-launcher; } anyways, but with better tooling support for that use-case.

[liquidnya]

Regarding that older configs can not be rebuid easily:

Recently I was rebuilding an old config of mine and it did fail to download the enpass package. This package has the unfree license, so the binary/package has not been cached! I did not look into why and just removed that package from my config and rebuilt it.

I think this problem has any package that is licensed as unfree. The distribution website could be down or have a different CA and so on and then older builds will fail.

So, I feel like ensuring that older builds do not fail for an unfree package could be asking too much? But I do not have any experience with that other than my very recent experience with enpass on my system.

[Janrupf]

So, I feel like ensuring that older builds do not fail for an unfree package could be asking too much? But I do not have any experience with that other than my very recent experience with enpass on my system.

While I agree, the hytale launcher updates so often (at least right now), that this becomes less of a "could" and more of a "will".

That being said, this has absolutely turned into bikeshedding at this point. I still stand by the fact that a runtime download makes sense: If you have an outdated launcher version, it will/might not let you play either way. So that helps you exactly not at all with rolling back

[CodedNil]

I agree runtime download makes the most sense, but wonder how that works in implementation. Would it download the launcher every time you run the run the desktop shortcut? I think the launcher is only about 20mb or something right, but how could it be cached with that strategy. Would it download it on launch only if it doesn't exist locally then let the launcher self update somehow after that without nix managing it?
Sorry if silly questions just not sure about these after reading all this thread.

[Ben9986]

I can see the runtime method kind of working but not sure how it would accepted by committers as it's kind of against the point of nixpkgs. Its effectively what we already have.

The current PR copies the latest version to $HOME/.local/share/Hytale/bin which puts it into an FHS env where it can auto update itself like it wants to.

I think the current method is functionally fine, if I'm understanding correctly all you need to do when the package is broken is go to https://launcher.hytale.com/version/release/launcher.json copy the version and the hash and put this in your config:

hytale-launcher.overrides = { 
  version = 2026-04-23-xyz; 
  hytaleHashes.x86_64-linux = "sha256-abc..."; 
};

The main issue is that the package will break like every 3-4 days so you would constantly need to update this manually unless you created your own local bash script which mirrors the update script here. We can see this from JPyke3's flake which implements a very similar solution to what we already have except it checks for an update every hour to ensure the flake still works whenever someone tries to use it.

I think so long as the package description clearly states that the user will more than likely need to use the above snippet to get an initial install, it may be acceptable. Or a link to the nixpkgs wiki where this is explained more in-depth would be better.

That being said, this has absolutely turned into bikeshedding at this point. I still stand by the fact that a runtime download makes sense: If you have an outdated launcher version, it will/might not let you play either way. So that helps you exactly not at all with rolling back

It would be bikeshedding if we were talking about a trivial issue, we're not. We're talking about merging a package that would be functionally broken 90% of the time and require manual overrides to work :)

[dtomvan]

I'm sorry if I come across as unconstructive or negative or whatever, but why would we even want a package for hytale in nixpkgs?

• Hypixel insists on the flatpak (IIRC they don't even allow playing the linux version in any other way)
• The package has to be broken (either due to impurities or hash mismatches) by the nature of the distribution of the software
• We don't go around packaging every unfree steam game out there (except balatro that I know of, but they rely on nix-store --add-fixed, and the only reason it's viable is because it's love2d)

Yes, we do package minecraft servers, but their distribution model actually allows packaging (pinned) versions. So as long as hytale isn't doing that, why bother?

[ItsLiyua]

I'd like to see hytale packaged even if it's just via a runtime download. It's the same that's done with steam and it still lets you somewhat declare what's on your system. If you have to imperatively install the flatpak there'll be components that aren't even named in the configuration file.
Even if it's not 100% reproducible it's still better than not packaging it at all.
You could add a warning to the build script that shows on every build unless it is disabled using an override.

[dtomvan]

[...] somewhat declare what's on your system. If you have to imperatively install the flatpak there'll be components that aren't even named in the configuration file

FWIW you could use nix-flatpak for that:

Details

{ pkgs, lib, ... }:
{
  services.flatpak.packages = lib.singleton rec {
    appId = "com.hypixel.HytaleLauncher";
    sha256 = "0ny8bqb0kklz1sg43ip45hhj2avai2zhdsiw244zk6qsfa2cnqj2";
    bundle = toString (
      pkgs.fetchurl {
        url = "https://launcher.hytale.com/builds/release/linux/amd64/hytale-launcher-latest.flatpak";
        inherit sha256;
      }
    );
  };
}

(for the record I haven't tested this but fairly certain it works however you'd have to update the hash now and again)

Or, even simpler, just write a oneshot job for that:

Details

{ config, pkgs, ... }:
{
  systemd.services.install-hytale-launcher = {
    after = [ "network-online.target" ];
    serviceConfig = {
      Type = "oneshot";
      PrivateTmp = true;
      User = "flatpak";
    };
    path = [
      config.services.flatpak.package
      pkgs.coreutils
      pkgs.curl
    ];
    script = ''
      if ! flatpak info com.hypixel.HytaleLauncher; then
        tmp=`mktemp /tmp/XXXXX.flatpak`
        curl -o $tmp https://launcher.hytale.com/builds/release/linux/amd64/hytale-launcher-latest.flatpak
        flatpak install --noninteractive --bundle $tmp
      fi
    '';
  };
}

(again, untested)

But you get the point, if your goal is "I want to declare Hytale somehow somewhere in configuration.nix", you have options already...

[ItsLiyua]

Yes but that's a hassle and also another flake input. People who just moved to nixos don't want to have to figure out how to add another channel to their config or migrate to a flake right away just to play a game. For steam the same thing was done to remove friction. I'd argue the devices that run steam or hytale won:'t be the devices that need 100% reproducibility.

[jjsuperpower]

I figured I pop my head back in this PR again as I was mentioned earlier. Let me preface this by saying I am more than happy to help contribute where it would be helpful, and I am not here to push an agenda.

...but why would we even want a package for hytale in nixpkgs?

Same reason as most other packages - convenience.

FWIW you could use nix-flatpak for that

Not a bad idea, but last time I tried to run the flatpak (which I will admit is a while ago) I was not successful. IMO Flatpak seems to be more of stop gap measure than a complete solution when it comes to nix.

I can see the runtime method kind of working but not sure how it would accepted by committers as it's kind of against the point of nixpkgs.

I'd actually argue this actually a good use case for nixpkgs. I agree with many people above that it is much more reproducible and true to nix to download the launcher at build time as a FOD. But due to how the Hytale launcher works, this approach requires frequent updates to the FOD hash. An independent repo with auto updates like what @JPyke3 did for his flake works well, but this is not feasible for nixpkgs. In this context, what nixpkgs is great for is convenience. I think it would be good to at least have the option of nix-shell -p hytale-launcher, like with steam.

Yes downloading the launcher at runtime is a solution that has technical dept. But I would still argue that a working solution with technical dept is better than a perfect solution that doesn't work.

Now what I would love to see the nix-hytale community focus on is the ability to set up a modded hytale server using a nix config/flake. Though that is probably out of scope for this discussion.

So now that I've stepped in it, my ego has requested protection against another round of downvote-mageddon /s.
I twirl my mustache

Please emote 👍 if you think that Windows > NixOS, please emote 👎 otherwise. There, my ego can now ignore the negative feedback :)

[Ben9986]

Yes downloading the launcher at runtime is a solution that has technical dept. But I would still argue that a working solution with technical dept is better than a perfect solution that doesn't work.

This isn't a working solution though. I'm not sure how no-one else seems to see this.
Once merged this package is only going to work for 3-4 days before breaking. I just don't see how this is sustainable.

It is not suitable for merging in this state.

Yes but that's a hassle and also another flake input. People who just moved to nixos don't want to have to figure out how to add another channel to their config or migrate to a flake right away just to play a game.

Quite frankly, people who have just moved to NixOS are not going to be able to use this package either. I'd argue that it's more of a hassle to have to figure out how to manually override the package version and compute the hash than it is to just see "there isn't a hytale-launcher package for NixOS. Guess I'll have to use the flatpak".

For steam the same thing was done to remove friction. I'd argue the devices that run steam or hytale won:'t be the devices that need 100% reproducibility.

The main, and crucial, difference with Steam is that they keep older versions of the .deb available on their servers for quite a while after they update, allowing us to download an outdated version from them if needed. Steam is also redistributable, meaning we can cache the built derivation on Hydra and not have to worry about losing the upstream source.
Hytale does neither of these, meaning this package build would 404 within a matter of days of being merged. It's not even an issue of reproducibility at this point, the package will simply be broken.

I'm sorry to just keep harping on about the same point but any hytale-launcher package is just going to be broken for the time being, until upstream allow redistribution or maintain older launcher versions on their servers.