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.
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
--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
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:
- Get the URL for the patch from monitor.nixos.org
- Run “update-package-def”
- 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
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,
We have another command (“container”) for container management. This tool has three subcommands:
- “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.
- “stats” which prints a simple table with statistics about your containers (name, IP, status and host key).
- “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 was added for downloading sources of packages into the store. So you can download all the sources you need for building a package and then disconnect from the Internet and rebuild your system while beeing offline.
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
The help texts were polished.
What’s up next
Well, there are some releases planned in the github issue tracker by now… Lets iterate:
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.
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:
- Update channels
- Rebuild the system
- Remove old generations
- run the GC
- Offer a reboot of the system
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!