-* Making the module files for a new application
-
- 1. Create a wizard/app/APPNAME.py file. Create an object Application
- inheriting from wizard.app.Application (check existing modules for
- the boilerplate code).
-
- 2. Implement download(). "wizard prepare-pristine" will use this in order
- to download the next version of an application.
-
- 3. Create a git repository with `git init`
-
- 4. Use `wizard prepare-pristine APP-VERSION` to download the tarball and
- extract it into the directory. If download() doesn't work and you don't
- want to special case it (for example, you need a /really old version/
- for record-keeping purposes), replace APP-VERSION with PATH, where PATH
- is the tarball to extract.
-
- 5. `git commit -asm "APP VERSION"`
-
- 6. Check if any patches are needed to make the application work
- on Scripts (ideally, it shouldn't.) Pre-existing patches
- live in /mit/scripts/deploy/APP-VERSION/ directories.
-
- 7. Run `wizard prepare-new` to setup common filesets for our repositories.
-
- 8. If you are running a PHP script, there is usually a php.ini file
- that we package. You can see previous instances of this patch
- at /mit/scripts/deploy/php.ini/ as well as in the repositories
- of any already migrated scripts. We hope to make these changes
- unnecessary once PHP 5.3 arrives.
-
- 9. Do an initial commit (we're gonna be amending the hell of this)
- using `git commit -asm "APP VERSION-scripts"
-
- 10. Implement install(). Test using `wizard install APP`; you won't
- be able to do a version-specific install with `wizard install APP-VERSION`
- until you generate a tag (which will become out of date once you
- amend the commit.) Now might be a good time to create a
- tests/test-install-APP.sh file (use the other tests as reference) so
- you don't have to constantly enter the parameters when you're doing
- an install.
-
- 11. Push your changes to a directory accessible in the production environment.
- In the case of scripts, this is equivalent to your AFS homedir, and
- the production environment is a scripts.mit.edu. We're going to
- perform a configuration in the production environment to extract
- out the canonical configuration files.
-
- 12. On the production server, call your wizard to perform an installation;
- be sure to use the option --no-commit in order to make propagating changes
- back easier. Inspect the generated configuration files (you can use `git
- status` to find unversioned files that the installer created), and
- implement:
- - extractors
- - substitutions
- These are dictionaries of functions that perform extraction
- and substitution of variables from config files. You don't
- actually have to hand code them; you can app.make_extractors
- and app.make_substitutions on a common dictionary. Check
- out wizard/app/__init__.py for more information on this
- format, as well as other files for samples.
- (XXX: extended instructions here)
- - parametrized_files
- These are any files that contain WIZARD_* variables
- - checkConfig()
- This is a simple, fs based check on whether or not the application
- was configured. Usually checking if some generated config file
- is present is sufficient
- - detectVersion()
- You might be able to reuse machinery from extractors (namely, whatever
- function you were using to generate regular expressions), or you might
- need to code a custom regular expression to parse this out.
- - deprecated_keys?
- Usually you won't need this; use it if there's a configuration variable
- that needs to get parametrized, but isn't actually necessary and
- gets obsoleted in a later version. You probably won't know if that's
- the case until later.
-
- 13. With these implemented, `wizard prepare-config` should now work if you run
- it on the installed copy. The configuration file should now contain only
- generic WIZARD_* variables, and no user-specific config. If it is, your
- script was buggy; try again.
-
- 14. The current changes in the working copy should be merged in. Add any new
- files, and then `git commit --amend`. `git push --force` to stick these
- changes back in the "public" repository.
-
- 15. In your local copy, you can pull the changes by doing `git reset --hard HEAD~`
- and then a `git pull` from the relevant source. Otherwise, Git will complain
- about a non-fast-forward.
-
- 16. Congratulations! You've implemented the installation code for a new install.
- Now goto "ENTER HERE FROM CREATING A NEW REPO" and finish the rest of the
- instructions.