SEP's software installation is comparable to installations of similar, publicly available packages. All the software employs makefiles and common commands such as make install or make clean.
However, improvements in the installation of GNU software (such as Perl, Emacs, and gcc) and the dynamics of the World Wide Web are challenging SEP to simplify its software installation mechanisms. SEP's major obstacles to more seamless installations stem from differences in platforms and user environments, and from the interdependencies of our software tools.
To deal with platform dependencies elegantly, GNU software uses configure scripts. Before installing a package, the configure script queries the system (e.g., it finds the available C compiler) and creates a system-dependent makefile. In general, the user installing the software does not need to think about platform dependencies. Configure scripts have tremendously eased the installation of many public domain software packages.
UNIX software that relies directly on local resources, such as printers and temporary disk space, are inherently difficult to export. On a remote system, the tmp disk space might be too small and the printer name is probably different from the local system. Reasonable standards (such as a default printer name ``Postscript'') could help, but UNIX lacks such standards. Consequently, packages are usually accompanied by README files that instruct users on how to change their environment appropriately. Such changes can be non-trivial since they often depend on the user's shell, and they can conflict with definitions due to other existing software.
On the other hand, SEP could use Sun's public domain software Modules. Modules supports shell independent environment definitions for individual packages, avoids naming conflicts, and therefore offers a convenient method of exporting environment variables. Unfortunately, users who download SEP software would be forced to install and use Modules on their computer system.
In contrast to much public domain software, SEP's packages are inherently hierarchical. For example, an SEP document will only function after SEPlib and the ReDoc rules have been installed. These dependencies are unknown to a novice to SEP software. The problems could be avoided if SEP would distribute all of its software as a single monolithic package (something SEP has done when creating CD-ROMs). However, because of the Internet's limited bandwidth, such large packages are difficult to distribute on the web. Alternatively, SEP could extend the configure concept: when installing an SEP software package, the configure script could check the local system and inform the user about additionally needed SEP software.
Java offers a very different alternative to exporting software on the web. Java's portability avoids the entire problem of platform dependencies. Java's security manager and its limited access to resources on a client recast the traditional environment problem in a very different and flexible way. Finally, Java's ability to dynamically load additional tools on the fly addresses the problem of complex software dependencies.