14 Apr 2004
(updated 14 Apr 2004 at 20:45 UTC) »
One of the guidelines in Halk is that presentations should be portable and self-contained as much as possible. They should ideally be seen as a file you drop to your hard disk. Running it and pointing your browser to some local port is all what would be needed. No installation, no setup.
This brings some internal issues, as what happens with custom preprocessors and beautifiers, but another kind of problem are dependencies.
Let's imagine you are giving a tutorial about some Python module which is not standard. The code in the presentation needs that module installed to run, what do we do? A solution is for the author to document that the presentation requires that module. Ugh. A presentation property could be some Perl code that checked dependencies so that the engine could warn the user with some informative message about what is missing and how to get it.
But I think an important number of cases can be solved if the config file provides authors with a mean to set environment variables. Since the presentation directory is owned by the author (in Halk's sense) he can install dependencies there. And since he is allowed to use filenames relative to the presentation root everywhere we can provide calls like
setenv 'PYTHONPATH', 'lib';
or for a presentation about some Java library:
setenv 'CLASSPATH', 'lib/*.jar', 'lib/*.zip', 'classes';
Those wildcards are possible with zero effort thanks to Perl's glob()
That won't cover all the cases, for instance if a library has native code and the author includes versions for several operating systems we can easily offer:
setenv 'LD_LIBRARY_PATH', 'linux_lib' if RUNNING_ON_LINUX;
setenv 'DYLD_LIBRARY_PATH', 'macosx_lib' if RUNNING_ON_MAC_OS_X;
So that trick would cover a few more. And in the end we always have a README as last solution :-).