From 624a38af2b96040384022413060861c3686447d6 Mon Sep 17 00:00:00 2001 From: Brian Picciano Date: Wed, 22 Sep 2021 22:04:16 -0600 Subject: update appimages with nix wording --- .../2021-09-22-building-appimages-with-nix.md | 37 +++++++++++----------- 1 file changed, 18 insertions(+), 19 deletions(-) (limited to 'static/src/_posts/2021-09-22-building-appimages-with-nix.md') diff --git a/static/src/_posts/2021-09-22-building-appimages-with-nix.md b/static/src/_posts/2021-09-22-building-appimages-with-nix.md index 956f912..612e601 100644 --- a/static/src/_posts/2021-09-22-building-appimages-with-nix.md +++ b/static/src/_posts/2021-09-22-building-appimages-with-nix.md @@ -29,7 +29,7 @@ fulfill the following requirements: * The builder itself should be deterministic; no matter where it runs it should produce the same binary given the same input parameters. -Lacking such a build system we're not able to distribute the program in a way +Lacking such a build system we're not able to distribute cryptic-net in a way which "just works"; it would require some kind of configuration, or some kind of runtime environment to be set up, both of which would be a pain for users. And lacking a definite build system makes it difficult to move forward on any other @@ -136,11 +136,11 @@ the `pkgs.buildEnv` used to create the AppDir (see AppDir section below). ## Process Manager -An important piece of the puzzle for getting our nebula project into an AppImage -was a process manager. We need something which can run multiple service -processes simultaneously, restart processes which exit unexpectedly, gracefully -handle shutting down all those processes, and coalesce the logs of all processes -into a single stream. +An important piece of the puzzle for getting cryptic-net into an AppImage was a +process manager. We need something which can run multiple service processes +simultaneously, restart processes which exit unexpectedly, gracefully handle +shutting down all those processes, and coalesce the logs of all processes into a +single stream. There are quite a few process managers out there which could fit the bill, but finding any which could be statically compiled ended up not being an easy task. @@ -179,11 +179,11 @@ places in the AppDir at `/etc/some/conf`. [These docs](https://docs.appimage.org/packaging-guide/manual.html#ref-manual) were very helpful for me in figuring out how to construct the AppDir. I then used the `pkgs.buildEnv` utility to create an AppDir derivation containing -everything the nebula project needs to run: +everything cryptic-net needs to run: ``` appDir = pkgs.buildEnv { - name = "my-AppDir"; + name = "cryptic-net-AppDir"; paths = [ # real directory containing non-built files, e.g. the pmux config @@ -229,7 +229,7 @@ generates the AppImage from a created AppDir: appimagetool, }: pkgs.stdenv.mkDerivation { - name = "program-name-AppImage"; + name = "cryptic-net-AppImage"; src = appDir; buildInputs = [ appimagetool ]; @@ -241,24 +241,23 @@ generates the AppImage from a created AppDir: chmod +w buildAppDir -R mkdir $out - # program-name needs to match the desktop file in the AppDir - appimagetool program-name "$out/program-name-bin" + appimagetool cryptic-net "$out/cryptic-net-bin" ''; } ``` Running that derivation deterministically spits out a binary at -`result/program-name-bin` which can be executed and run immediately, on any -system using the same CPU architecture. +`result/cryptic-net-bin` which can be executed and run immediately, on any +system using the `x86_46` CPU architecture. ## Fin -I'm extremely hyped to now have the ability to generate binaries for our nebula -project that people can _just run_, without them worrying about which -sub-services that binary is running under-the-hood. From a usability perspective -it's way nicer than having to tell people to "install docker" or "install nix", -and from a dev perspective we have a really solid foundation on which to build a -quite complex application. +I'm extremely hyped to now have the ability to generate binaries for cryptic-net +that people can _just run_, without them worrying about which sub-services that +binary is running under-the-hood. From a usability perspective it's way nicer +than having to tell people to "install docker" or "install nix", and from a dev +perspective we have a really solid foundation on which to build a quite complex +application. [lastnix]: {% post_url 2021-04-22-composing-processes-into-a-static-binary-with-nix %} [nix-bundle]: https://github.com/matthewbauer/nix-bundle -- cgit v1.2.3