update appimages with nix wording
This commit is contained in:
parent
9655dc6677
commit
624a38af2b
@ -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 `<AppDir-path>/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
|
||||
|
Loading…
Reference in New Issue
Block a user