1 Wizard originally grew out of a simple itch for MIT Scripts
2 autoinstallers: we had grown a suite of tools for letting
3 users easily install web applications, but we had been completely
4 negligent in keeping these applications up to date. There was
5 automation to be built, and Wizard originally was meant to let
6 us perform updates on these autoinstallers.
8 As subsystems started being built, I started to notice that
9 Wizard was starting to develop into something more generally
10 applicable than just "mass upgrades for Scripts autoinstalls"--
11 perhaps the first instance of this was when I noticed that there
12 wasn't really any good reason that 'wizard upgrade' couldn't
13 be run by the user, and not just us in the process of a mass
16 Wizard wants to solve three problems:
18 1. It is a better package manager for web applications.
19 This means making it easy to install and upgrade web applications,
20 all of which may be coexisting on the same machine (something
21 traditional package managers don't manage well.) It also means
22 bringing a /consistent/ interface for maintaining all applications
25 2. It solves the problem of maintaining your own patchsets on top
26 of an application, and not just getting those blindly written
27 over and getting intelligent merging and conflict markers of
30 3. It enables to do this on a large scale, on the order
31 of thousands of installs. To do this, we also standardize
32 an interface for backing up filesystem and non-filesystem data