Revision history [back]

After looking at both disk images and looking for things online, before installing anything, I have some partial answers:

1. There are extended installation instructions included in the distribution disk images does give different instructions for each distribution; the instructions on the website are only for the non-app distribution. Looking at the content of the disk images I see these differences in the directory structures:

   • On the "non-app" image, the sage distribution is in /sage/; on the "app" image, the sage distribution is in /Sage-6.1.1.app/Contents/Resources/sage/
   • Within those pathes, the only differences are within ./.git/ (which probably shouldn't be included)
   • Between those pathes, the "app" image has what appear to be files intended to wrap the distribution in a MacOS Application bundle
   • Both images include identical /README.txt and an empty (and unnecessary) /.Trashes/

2. While the non-app distribution must be installed somewhere, it is not clear why the instructions use /Applications/.

   • It seems that in Mac OS, functionality not implemented in Applications but intended to be used by Applications should be packaged as Frameworks and installed in /Library/Frameworks/. This is done, for example, by the official Mac OS installers of Python and Mono. Most of the relevant information is linked from http://stackoverflow.com/questions/1444543
   • It seems that in Mac OS, command-line executables (consisting of a single file) are often installed in /usr/local/bin/. I couldn't find any documentation of the general rule, but it was easy to find several posts in various forums which refer to that path for different particular command-line tools.
   • I did not find any indication of where large dependencies should be installed to support executables in /usr/loca/bin/ (other than as Frameworks). I would guess that if the executable goes in /usr/local/bin/ the libraries would go in /usr/local/lib/, but it was not easy to find many posts which refer to that path.

3. The instructions on the website are only for the non-app distribution. Since it does not include an Application bundle, only a command-line executable, it says to tell finder to open the command-line executable in the Terminal. I think it would be better to put the binaries elsewhere (either in a Framework or /usr/local/lib/) and only put an alias in /Applications/.

4. It's not clear why the image with more data takes up less space.

   • The file containing the app image is 5,400,527 bytes smaller than the file containing the non-app image. The content of the app image is 810,425 bytes larger (although the .git pathes differ, they have the same size). Disk Utility shows each image has the same amount of unused space, and the app image has 866,304 bytes more capacity.
   • These are compressed disk images, so the app image might be more compressible. If the added data compressed to zero that wouldn't make the image smaller. On each image the .git path contains 76,036,793 bytes, so a difference in compressability there could explain the difference in image size, but it seems unlikely that .git would have such a difference.
   • If the .dmg/UDIF format is essentially a byte-for-byte image of what would be on a partition, differences in the filesystem could affect compressibility. (see http://en.wikipedia.org/wiki/Apple_Disk_Image ) While I imagine they do exist, I'm not aware of any tools that could either reveal such differences or optimize the images.
   • Both disk images are larger than the sizes given on http://www.sagemath.org/mirror/osx/intel/index.html

5. According to the extended installation instructions included in the distribution disk images, the app distribution can create a symlink to the command-line executable in /usr/local/bin/ after installation.

6. Running sage as a background service is not currently supported, but may be possible by unsupported means.

   • The feature is scheduled to be added in Sage 6.2, but was previously scheduled to be added to Sage 5.11. See http://trac.sagemath.org/ticket/381
   • Some unsupported means (not Mac-specific) are given at http://ask.sagemath.org/question/1023/how-to-run-sage-as-a-service
   • An apparently unofficial effort to make a Linux-style control script for sage as a background service is available at http://trac.sagemath.org/attachment/ticket/7893/sage-notebook-server
   • If the UI is to be run locally, I suspect using the App to provide a better UI than the service and a web browser. It's not clear from the READMEs weather any functionality is available in the interactive shell but not the notebook, or vice-versa.

It seems like the "right way" on Mac OS would be to make Sage essentially a Framework, with a companion Application that relies on the Framework for most of its functionality. Without an installer, the disk image could follow the common practice of having the Application icon appear next to a shortcut to /Applications/ with an arrow indicating to copy one into the other, repeat that for the Framework and /Library/Frameworks/ (or the library dir and /usr/local/bin/), and keep the option in the Application to add a link to the command-line executable in /usr/local/lib/. Documentation on the website should explain the two, and that it's OK to install only the Framework. Once the Framework supports running as a background service, the same documentation should include instructions for using the browser UI with or without the Application installed.

And with that, I'll try installing from the app image.