balsoft

It’s the fact that Mercurial tags the commit with the name of the branch that it was committed to which makes it much easier to determine whether a commit is included in your current branch or not.

Isn't this trivial in Git too? git branch --contains COMMIT ?

Glad to hear you got it working!

The issue is that network-online.target does not necessarily mean that you actually have internet access, it usually just means that you have an IP address. I've found that it can take a dozen seconds to actually get internet connectivity, depending on your setup. As a hack, you can add while ! ping -c1 ghcr.io; do sleep 1; done or similar to PreStart of your container services.

Would be so cool to have something like this for Nix (with appropriate accommodations for packages and NixOS modules, and some Flake search too).

(Actually, bhoogle is stuttering a lot with some queries - looks like the TUI rendering and search happen in a single thread. Not cool.)

Wait, is #haskell still on Freenode? I thought they migrated to libera.chat during the Freenode collapse

You're welcome!

The issue I see with your approach is that you’re looking for a tutorial for something that is basically infinitely flexible, there’s multiple ways to do things, etc.

I don't think this is the right approach either TBH. Even general-purpose programming languages often have "tutorials" to guide you through the basics of writing your first couple of programs, explaining all the steps without showering you with too much details about internals. Think Rust By Example or Real World Haskell. I feel like NixOS urgently needs something like this - a half-dozen (relatively) simple configuration examples, from the shortest one possible that gives you the minimal useable system, all the way to a flake-based setup that configures multiple machines, both headless and GUI-enabled, with appropriate code reuse. Don't get me wrong, those resources are there if you look for them, someone just has to compile them and get them into official docs.

In this case what I would recommend is to provide a command (perhaps inside that nix develop) that would set up all the images/services/data, and a second one to tear it down, and allow devs to run those commands themselves. This allows for more flexibility, e.g. multiple nix develop shells of the same project, but only one does the stateful stuff, coming back to the same shell later in the day without waiting for the setup. Most importantly it would allow for easy clean-up if the shell is shutdown unexpectedly and doesn't have time to clean up itself, e.g. SIGKILL or power loss. It can be as simple as using writeShellScriptBin to string together commands (instead of doing it in the shellHook as you presumably are doing right now), or as complex and flexible as https://github.com/svanderburg/nix-processmgmt .

Then, if you really want to automate it, you can simply add your-setup-command and trap "your-cleanup-command" EXIT to your shellHook.

You can try out Nix. It can be installed right there on your Kubuntu box, without any conflicts with apt or other package managers.

It's somewhat similar to portage with its ebuilds in that it's source-first and allows you to set up complex dependency trees and configure every package in them. In your case it would allow you to avoid manual rebuilds and just build&install all your custom software with one command from one directory containing some .nix files that describe how to fetch, configure and compile every package. (Actually, for your dependencies those files are likely to be in nixpkgs already - you can check at https://search.nixos.org/packages. In that case, you don't have to write any packaging instructions or even build everything, as Nix will intelligently download the binary versions which are helpfully provided by the Nix community).

It's quite different from most other package managers/build systems, though, being much "simpler" (it can be described as lambda calculus on files with syntax sugar) but much "harder" (the learning curve is actually a learning wall with the first section requiring mountain climbing experience and covered in barbed wire). If you've been maintaining builds for multiple packages by hand for years, though, it shouldn't be too bad.

Very few things are trully impossible in linux land, but having multiple package managers on a single system is just asking for trouble.

Nix/Guix (and a couple other similar package managers) are specifically designed to not interfere with the rest of your system.

This is a pretty good list of tutorials for Nix (as the package manager thingy) (not NixOS): https://nix.dev/tutorials/#tutorials

Here's a tutorial for the Nix language: https://nix.dev/tutorials/nix-language

As for the configuration.nix file, TBH, once you understand the Nix language you can just go around and look at what other people have written to get the inspiration. There's a list of NixOS configs here: https://wiki.nixos.org/wiki/Configuration_Collection. Some of them are quite complex (as is mine), but you can start with something simple, maybe like this: https://bitbucket.org/bzz/nixos/src/master/configuration.nix . It will give you an idea of how to set config options and how the imports system works. To then see which config options are out there, look at https://search.nixos.org/options , you can search for anything you like (e.g. services, programs, networking, random system configuration stuff). You should never ever edit anything in /etc other than configuration.nix manually, always look for config options to do it.

There's technically documentation about it here: https://nixos.org/manual/nixos/stable/#sec-configuration-file , which can be helpful, but it's also kinda long for what it tries to explain.

Once you get the basics, you can look into flakes to replace stateful channels, making your configuration more modular to reuse it across multiple machines (now it'd be time to look at those more complicated configs), using home-manager to also manage your $HOME (so that you don't have to touch ~/.config manually either), and maybe even impermanence to make your system reset to whatever is in your NixOS config on every reboot, erasing any accidental edits to configs, to make sure that your configuration reflects what exactly you want from your machines.

Nah, the language itself should be as simple as possible. Bloating it with endless extensibility and features is exactly what makes Perl a write-only language in many cases and why it is becoming less and less relevant with time.