# nixos-scripts version 0.3

I just noticed that I have no blog article about nixos-scripts version 0.3 yet, though the tool was released exactly one month ago.

So I catch up on this now.

# Changelog

The third release contains some neat things for the “switch” and the “update-package-def” command, lets start with the latter.

The “update-package-def” command is now able to translate arguments for --cores and --max-jobs now, so you can pass the number of cores or jobs to use for the build. This is extremely helpful for updating large packages. I myself happen to maintain a set of rather small packages, but from time to time I want to update packages I do not maintain, for example i3 or similar packages. Building these packages with more jobs results in much better build time, especially on my OctaCore processor.

The “update-package-def” command is now able to push to a pre-configured remote after successful build now. So your update-workflow is a bit smoother now:

1. Get the URL for the patch from monitor.nixos.org
2. Run “update-package-def”
3. Create pull request on github

The “switch” command got some neat updates as well. First of, the command is now quiet by default. This means you don’t get this noisy output anymore when updating your system, as nixos-rebuild is called with -Q now. The command has changed some background behaviour: The nixpkgs repository (if known) gets updated (via git fetch) before a tag is created. This way we can be sure the commit exists before creating a tag on it. Tagging is now disabled for build as command type. Also the codebase was refactored, so its maintainability was improved a bit.

Another big point is the “channel” command. We have commands for channel updates now, they also create tags in your configuration repository. My workflow for updating my system is now:

nixos-script -v channel update
nixos-script -v switch


Which updates the channel with the first command and rebuilds the system with the second command. I don’t use the nix-* commands anymore for my system, really!

We have another command (“container”) for container management. This tool has three subcommands:

1. “setup” for building a new container from a template. You can specify a configuration.nix file, which will be copied to the container after it is created. It will call your editor to customize the configuration file right afterwards and rebuild the container then.
2. “stats” which prints a simple table with statistics about your containers (name, IP, status and host key).
3. “kill” kills a container and gives you the option to destroy it as well.

More options will be added to the container subcommand as soon as I need them. We’ll see…

The “show-generation” command is now able to show generations from a custom profile.

A tool I’m rather proud of is the REPL I’ve added. Its capabilities are limited, but I’m still a bit proud of it. So you can have a simple “shell” where you don’t need to type nixos-scripts all the time. Normal bash commands are allowed as well, though functionality is limited here. It also lacks features like autocomplete and “one up for last command” or these things…

The help texts were polished.

# What’s up next

Well, there are some releases planned in the github issue tracker by now… Lets iterate:

## 0.4

This release will contain auto-complete for all the things. Nothing more, nothing less. It is something like an one-feature-release. I hope to get this done soon, but at the moment I really have no time to work on nixos-scripts, so … feel free to send me pull requests to help me there.

## 0.5

The 0.5 release will introduce user-defined functions. So the user is allowed to put custom code in the configuration file and these functions will then be used for generating the tag names for example.

I’m really looking forward to this, as I do not want to restrict the user in matter of tag names my scripts generate in the users configuration repository. Backward compatibility will be provided, though.

Another feature I want to include is a (sort of) meta-command, which updates and cleans the system in litterally one step:

1. Update channels
2. Rebuild the system
3. Remove old generations
4. run the GC
5. Offer a reboot of the system

## 0.6

As the 0.4 and 0.5 releases are sort of one-feature-releases, this release will introduce all the small fixes and cleanups, new functionality for commands and so on. As this milestone gets rather big on github, I may split it into 0.6 and 0.7, I don’t know yet.

So that’s it. I apologyze for writing this post now, not one month ago. Though I’m not committing to the repository at the moment, the project is not dead, really! Feel free to send pull requests and issues!

Stay tuned!