+ - A .scripts directory, with the intent of holding Scripts specific files
+ if they become necessary.
+
+* 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.
scripts.mit.edu / wizard.git / blobdiff