Hello dewi users! (Yes, all three of you.)
I started developing dewi in 2010. Back then I did two releases in less than a week. And now the third release gets out more than six years later. There are a number of reasons for the amount of time this took: I made a few mistakes in dewi's design, and fixing them took some effort. Spare time got really scarce. I wasted some time implementing features, that should never have been part of dewi (because they were features, my previous solution to this problem had). I wanted lots of features, that took a while to finish. Because the new release would definitely break backwards compatibility, I was working on a separate branch called “onward”, that basically only I used. And finally, since the code in that “onward” branch worked for me (I knew its shortcomings and worked around them), I could not motivate myself to fix all the outstanding issues and add proper documentation for all that had changed. Therefore nothing happened.
In the meantime, other systems like vcsh, rcm or homesick have emerged. Really, there are tons of systems like these out there, these are just a few of them that get mentioned to me more often than the others. Some of these systems hard depend on a version control system — usually git — and even have it at their absolute centre of implementation. Others just made pretty weird design decisions, that make me feel uneasy. And yet others are just a little limited in what they can actually do (basically just symlink a file). I still prefer dewi over everything I have looked at in any sort of detail.
Earlier, I mentioned some mistakes in dewi's design. Let's take a look at some of them: First, I should have never depended on ‘make’: Dewi only used it to call the dewi script (from .dewi/bin) and because the "make deploy" looks pretty. But there's no feature in make that the basic dewi features actually need. And then you just end up with a bunch of downsides, like:
- Superfluous dependency, that a target system has to satisfy
- Proper portable make code is actually not that easy, and I always get issues on OpenBSD systems for example.
- Using make required a Makefile in each dewified sub-directories to exist. Which means that you pollute the sub-directory's version control history with changes to that file each time dewi updates it.
- If someone wants to use make as part of their deployment system, they can use it on top of a make-less dewi-system at will.
- Needlessly complicates the whole system.
You can think of more. It was just wrong to use ‘make’.
And the second major mis-design was the case of keeping the code for dewi in the dot-dewi sub-directory. The idea was to ensure, that the deployment process doesn't ever break due to changes in dewi that might be in updated system version. That's still a moot point however, since nobody keeps someone from installing a fixed version of dewi into ‘~/bin’ and never ever change it. Dewi can be used from its source directory as well and its non-standard dependencies (dewi's implementation language, Perl, is installed on virtually all systems I have come across) are optional dependencies; no need to install anything. Instead, keeping the script in the ‘.dewi/’ directory made the system much less clear and much more confusing.
These issues are both fixed now. Dewi is now a single command line tool, that ships all its code. And where you previously did this:
% make deploy
…you are now doing this:
% dewi deploy
To discuss all changes in dewi since version 0.2 would completely go beyond the scope of a single blog post. Instead, let me list a few highlights:
- You can now apply filters when deploying files (useful, if your configuration files carry sensitive information).
- You can now use multiple input files to deploy into a single destination file.
- Dewi now lets you run your own code while it works, because it lets you define hooks.
- Dewi now has better support for deploying large, recursive trees of files.
- You can now deploy files with full support of templates using Perl's Template module (available from CPAN).
Another thing that may be interesting for a few users is the trivial call of its register() function: That one takes a string argument, that is the name of a source file. Its effect would be to deploy that file using the copy method, after the source file name was turned into a dot-file-name. Copying was the default choice of deployment, because it absolutely works everywhere.
However, sometimes you may want to take changes you do to source files immediately after saving them to disk. You may think “symbolic links!” right now and you would be right. The trivial call style of register() now allows the user to supply string-options. So now the canonical example of a Dewifile for a git-configuration that should be symlinked to its source looks like this:
register '--symlink', 'gitconfig'; end
For all details, take a look at the CHANGES and UPGRADING files as well as the new and updated manuals dewi(7), dewi(1) and dewifile(5) (see below).
I am planning to release version 1.0 of dewi based on version 0.3 once it had time to settle a little and have remaining bugs fixed, if they come up, and to have its documentation be polished further. I consider dewi to be pretty feature complete right now, which is why after 1.0 it'll go to maintenance mode.
Thanks for listening. ☺