swc-installation-test-2.py: Prefer distro to platform.linux_distribution

platform.linux_distribution was deprecated in 2015 to be removed in
Python 3.7 [1,2].  And it may not exist at all on some Python builds
(Manjaro's [3]?).  Prefer distro (the replacement PyPI package [4,5])
on Linux if the user already has it installed.

If we can't find a distro/version, use '*' for generic help-URL
matching.  And silently skip distro/version information in
print_system_info.

[1]: http://bugs.python.org/issue1322#msg243063
[2]: https://docs.python.org/3/library/platform.html#platform.linux_distribution
[3]: https://github.com/prerit2010/swc-setup-installation-test/issues/7#issuecomment-231573710
[4]: http://bugs.python.org/issue1322#msg263896
[5]: https://pypi.python.org/pypi/distro

swc-installation-test-2.py: Disable sympy, Cython, networkx, and mayavi.mlab

These are rarely used in SWC workshops, and many instructors are
pointing their students at these installation-test scripts without
customizing CHECKS first.  Until we get an easier way to configure the
checks, just make the default settings a bit more relaxed.

swc-installation-test-2.py: Comment explaining implemention

Merge branch 'version-plist'

Version checks for some OS X applications that don't support a
--version option.  Andrew Walker confirmed that this found his Safari
version on OS X 10.6.8, but the code is otherwise untested [1].

[1]: https://github.com/swcarpentry/workshop-template/pull/108#issuecomment-71517251

* version-plist:
  Fix decorator in VersionPlistCommandDependency
  swc-installation-test-2.py: Convert PathCommandDependency to VersionPlistCommandDependency

Fix decorator in VersionPlistCommandDependency

This class includes a static method that calls a
static method and this fails with:

$ ./swc-installation-test-2.py safari
check Safari (safari)... Traceback (most recent call last):
  File "./swc-installation-test-2.py", line 1007, in <module>
    passed = check(args)
  File "./swc-installation-test-2.py", line 243, in check
    version = checker.check()
  File "./swc-installation-test-2.py", line 298, in check
    return self._check()
  File "./swc-installation-test-2.py", line 340, in _check
    version = self._get_version()
  File "./swc-installation-test-2.py", line 536, in _get_version
    return self._get_version_from_plist(path=path)
  File "./swc-installation-test-2.py", line 527, in _get_version_from_plist
    value = self._get_next(root=tree, element=key)
  File "./swc-installation-test-2.py", line 511, in _get_next
    parent = self._get_parent(root=root, element=element)
NameError: global name 'self' is not defined

Change the static method _get_next (which is not passed self when
called) to a class method (which is passed the class object) so
that we can call the _get_parent static method (whatever the class is
called).

swc-installation-test-2.py: Convert PathCommandDependency to VersionPlistCommandDependency

Philip Guo suggested using version.plist to lookup the version number
for applications on OS X [1].  Searching around, I found an example of
Safari's version.plist posted by ASmit010 [2]:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
       <key>BuildVersion</key>
       <string>1</string>
       <key>CFBundleShortVersionString</key>
       <string>5.1.7</string>
       <key>CFBundleVersion</key>
       <string>7534.57.2</string>
       <key>ProjectName</key>
       <string>WebBrowser</string>
       <key>SourceVersion</key>
       <string>7534057002000000</string>
  </dict>
  </plist>

Looking at that example, the version information we want is associated
with CFBundleShortVersionString [3]:

  CFBundleShortVersionString (String - iOS, OS X) specifies the
  release version number of the bundle, which identifies a released
  iteration of the app. The release version number is a string
  comprised of three period-separated integers. The first integer
  represents major revisions to the app, such as revisions that
  implement new features or major changes. The second integer denotes
  revisions that implement less prominent features. The third integer
  represents maintenance releases.

  The value for this key differs from the value for CFBundleVersion,
  which identifies an iteration (released or unreleased) of the
  app. This key can be localized by including it in your
  InfoPlist.strings files

The sibling-entries for keys and values are a bit awkward using
Python's stock ElementTree [4,5], which doesn't have built-in methods
for finding parents or siblings [6].  I've followed the example set by
lxml and added _get_parent and _get_next helpers (mirroring getparent
[7] and getnext [8]) to make it the logic in _get_version_from_plist
more clear.

[1]: https://twitter.com/pgbovine/status/559094439009075203
[2]: https://discussions.apple.com/message/19757845#19757845
[3]: https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-111349
[4]: https://docs.python.org/2/library/xml.etree.elementtree.html
[5]: https://docs.python.org/3/library/xml.etree.elementtree.html
[6]: http://lxml.de/1.3/api.html#trees-and-documents
[7]: http://lxml.de/api/lxml.etree._Element-class.html#getparent
[8]: http://lxml.de/api/lxml.etree._Element-class.html#getnext

swc-installation-test-2.py: Add minimum browser requirements for IPython

IPython notebooks (at least for version 1.2.1 [1], 2.3.0 [2], and
3.0.0 [3]) have the following minimum browser requirements:

    Chrome ≥ 13
    Safari ≥ 5
    Firefox ≥ 6

Due to the notebook's usage of WebSockets and the flexible box model
[1,2,3].  This commit ensures that folks requiring IPython have a
notebook-compatible browser.

We don't actually check the Safari version, because I'm not sure what
the appropriate command-line switch is to get it to print version
information.

[1]: http://ipython.org/ipython-doc/1/install/install.html#browser-compatibility
[2]: http://ipython.org/ipython-doc/2/install/install.html#browser-compatibility
[3]: http://ipython.org/ipython-doc/dev/install/install.html#browser-compatibility

swc-installation-test-2.py: Collect classes together

Instead of interleaving class definitions with their instantiation.
This will make it easier to build dependency chains that mix a few
classes, because we don't have to worry about whether or not that
class has been defined yet.

README.md: Change headers ("Students" -> "For leaners")

This is based on swcarpentry/workshop-template@5451fb9c1 (Enumerating
setup/run instructions for installation test scripts, 2014-12-17).
Greg suggested he switch from "Students" to "Learners" because some
professors attend workshops as students but don't feel comfortable
being called students [1]?  Or something like that.  I don't mind
either way, so we'll just go with Greg's preference.

The addition of a "For" in the section headings seems like a good
change though, since it makes it clear that the noun in the heading
marks the intended audience for that section, not the intended
subject.

I went with 'Sentence case' titles because I think they're more
readable and it's easier to be consistent.  There are a number of
folks who agree with me [2,3], including (apparently) the Oxford Guide to
Style [4] (I'm ok with title case for book and organization titles ;).
Although the American Psychological Association perfers 'Title Case'
for the first two levels of headings as well [5].

[1]: https://github.com/swcarpentry/workshop-template/pull/89#issuecomment-67718126
[2]: http://www.snappysentences.com/sentence-case-v-title-case/
[3]: http://www.stickycontent.com/blog/are-you-team-title-case-or-team-sentence-case.php
[4]: http://ux.stackexchange.com/a/48620
[5]: http://blog.apastyle.org/apastyle/2012/03/title-case-and-sentence-case-capitalization-in-apa-style.html

Based-on-patch-by: Greg Wilson <gvwilson@third-bit.com>

swc-installation-test-2.py: Bump minimum IPython version to 1.0

I see the README recommends IPython >= 1.0 [1], but this script was
only looking for >= 0.13.  The busy bees at IPython have recently cut
2.3.0 (2014-10-01 [2]).  IPython 2.x has a bunch of changes including
deprecating the file/ prefix for local files [3] and adding a modal
interface [4].  I asked for feedback on what versions we were
supporting, and got this from Matt [5]:

On Thu, Sep 18, 2014 at 11:40:04AM -0700, Matt Davis wrote:
> I just did a quick check of opening a 2.2 made notebook with IPython
> 1.1 and it worked fine. There were some new features in IPython 2
> like notebook signing and the idea of "trusted" notebooks, but the
> format seems to be compatible with IPython 1.

So this commit bumps the minimum version to 1.0.  We'll revisit this
compatibility after the IPython folks cut 3.0.

[1]: https://github.com/swcarpentry/bc/blob/v2014.06/README.md#faq
[2]: https://pypi.python.org/pypi/ipython/2.3.0
[3]: http://ipython.org/ipython-doc/dev/whatsnew/version2.0.html#directory-navigation
[4]: http://ipython.org/ipython-doc/dev/whatsnew/version2.0.html#modal-user-interface
[5]: https://github.com/swcarpentry/bc/issues/724#issuecomment-56083316

README.md: Convert 'boot camp' -> 'workshop'

Following Amy Brown's [1]:

> We borrowed the "bootcamp" terminology from Hacker Within and also
> various fitness training camps, but as we branch out into parts of
> the world with a more violent recent history I'm less comfortable
> with the term.

The consensus on that issue was to change back to our old 'workshop'
terminology.  The swcarpentry/bc repository hasn't made the shift yet,
but there's no reason I can't embrace the future here ;).

[1]: https://github.com/swcarpentry/bc/issues/240

swc-installation-test-2.py: Prefer pip to easy_install

For virtual-pypi-installer.  easy_install is part of Setuptools [1],
which was dead for several years.  The Distribute fork took over, but
has since been merged back into a revitalized Setuptools (since
Setuptools v0.7 [2], tagged on 2013-06-02 [3]).  Pip >= v1.4 actually
requires a modern Setuptools, not Distribute [4].  Pip also improves
on easy_install [5], which does not currently support uninstalling
packages [6].

[1]: http://pythonhosted.org/setuptools/
[2]: http://pythonhosted.org/distribute/
[3]: https://bitbucket.org/pypa/setuptools/commits/tag/0.7
[4]: http://www.pip-installer.org/en/latest/installing.html#id6
[5]: http://www.pip-installer.org/en/latest/other-tools.html#easy-install
[6]: http://pythonhosted.org/setuptools/easy_install.html#uninstalling-packages

README.md: Remove nesting setup/

There's no need to hard-code target directories in this repository.
Anyone consuming this material can use submodules and pick their own
target directory.

swc-installation-test-2.py: added support for py.test

swc-installation-test-2.py: Use ProgramFiles environment variable

On Fri, Apr 26, 2013 at 11:45:12AM -0700, Onno Broekmans wrote:
> ... the installation paths you mention are incorrect for the
> majority of modern Windows 7 installations. These are 64-bit
> installations, and they have a special folder for 32-bit programs:
> "C:\Program Files (x86)". So Notepad++ can be found in:
>
>     C:\Program Files (x86)\Notepad++\notepad++.exe
>
> In the script, you could just check for the program's existence
> using both paths ("C:\Program Files" _and_ "C:\Program Files
> (x86)"), or you could use the "ProgramFiles" environment variable.

Environment variable it is!  From the Microsoft docs [1]:

  CSIDL_PROGRAM_FILESX86
    The Program Files folder on 64-bit systems. A typical path is
    C:\Program Files(86).
  ...
  CSIDL_PROGRAM_FILES
    Version 5.0. The Program Files folder. A typical path is
    C:\Program Files.
  ...
  PROGRAMFILES
    Same as CSIDL_PROGRAM_FILES.
  PROGRAMFILES(X86)
    Refers to the C:\Program Files (x86) folder on 64-bit systems.

We're just looking for executables, so it would be ok if we found a
32-bit Notepad++ or a 64-bit Notepad++.  With this commit, we check
both locations (if there are two distinct locations).

[1]: http://technet.microsoft.com/en-us/library/cc749104%28v=ws.10%29.aspx

swc-installation-test-2.py: Also look for extension-less paths

Before this commit, CommandDependency checked self.command (with an
optional extension determined by distutils).  If that check failed to
produce a version stream, we cycled through a list of additional
hard-coded paths.  For example:  Notepad++ used:

  self.command = 'notepad++'
  self.paths = [
      _os.path.join(
          _ROOT_PATH, 'Program Files', 'Notepad++', 'notepad++.exe'),
      ]

Because some MS Windows commands lack the expected '.exe' extension,
but are still present and detected by a number of shells, we should
also look for the extension-less version of the command.

I consolidated the _get_version_stream() logic to build a single list
of paths and loop through it looking for success (and accumulating
errors).  This makes the handling of self.paths less of a special
case, and sets us up for any additional path mangling we may need to
support other poorly standardized OSes ;).

swc-installation-test-2.py: Add CommandDependency.paths fallbacks

The old CommandDependency implementation assumed that commands would
exist in one of the directories listed in PATH.  This assumption is,
unfortunately, often not satisfied on MS Windows or OS X.  In order to
work around this problem, you can now store a list of fallback paths
that will be tried if there is an error extracting the version stream
from the bare CommandDependency.command.

I've added fallback paths for Notepad++, Firefox, and Google Chrome,
as reported by Ethan White for Windows 7.

swc-installation-test-2.py: Use _ROOT_PATH for MS Windows compatability

I don't think starting a path with os.sep gives you a root path on
Windows.  We need the backslash in _ROOT_PATH, because:

  os.path.join('c:', 'foo')

gives 'c:foo', a path relative to the current directory on drive C: [1].

[1]: http://docs.python.org/3/library/os.path.html#os.path.join

swc-installation-test-2.py: Raise an error on empty version stream

This makes the upcoming mult-path checking easier to implement.

swc-installation-test-2.py: Don't override Popen's 'close_fds'

Or 'shell'.  The support for these options can be flaky, and the
defaults change with Python version depending on what is best
supported [1].

[1]: http://docs.python.org/2/library/subprocess.html#subprocess.Popen

Reported-by: Ethan White <ethan@weecology.org>

swc-installation-test-2.py: Add 'safari'

This works adds support for virtual-browser on OS X.  Matt Davis
reports the locations of Firefox and Chrome as:

  /Applications/Firefox.app
  /Applications/Google\ Chrome.app

but I'm not sure where the executables live underneath those
directories, which we'd probably need if we wanted to extract version
numbers.

swc-installation-test-2.py: Link directly to install docs

Expecting the Software Carpentry maintainers to keep up-to-date
documentation for each system/package pair is not realistic.  Instead,
link to each package's installation instructions (as best I can find
them).  The system/version/package globbing (using fnmatch, see
glob(7)) makes it easy to setup per-system and per-version URLs if you
want to fine-tune the instructions.

swc-installation-test-2.py: Add --help and --verbose

The system information is useful for troubleshooting a student's
installation problems, but it is probably less useful for the student
themselves.  Turn off this troubleshooting information by default and
require the --verbose option to re-enable it.

If we didn't have to maintain support for Python 2.6, we could use
argparse instead of optparse.  The optparse module is deprecated for
2.7, 3.2, and later, but it is still part of the stdandard library.

Also update the README to point out --verbose.

swc-installation-test-2.py: List supported Ubuntu install hints

From http://software-carpentry.org/setup/ubuntu.html, in the order
that they are currently listed.  The page sections don't have the
appropriate anchor IDs yet, but it's still better to link to the
Ubuntu page than to the root setup/ page.

swc-installation-test-2.py: Add support for package-specific URLs

To give users more targeted advice for fixing their installation
problems, we should link them to somewhere more specific than the root
SWC setup page.  The two knobs in the specific URL are system/OS
(Gentoo, Debian, OS X, MS Windows, ...) and package (the dependency
name: emacs, git, virtual-browser, ...).  We don't have consistent
URLs upstream yet [1], but maybe this commit will help motivate them
;).

[1]: https://github.com/swcarpentry/website/issues/2

swc-installation-test-1.py: Link to s-c.o's terminal.html

For screen shots and additional platform support.

swc-installation-test-2.py: Add 'argparse'

I use this module (which entered the stdlib in 2.7/3.2) in my
get-my-ip.py script (in a different branch at the moment).  Users with
older Python implementations will have to install an external module
(e.g. from PyPI).

swc-installation-test-2.py: Add 'EasyMercurial'

Chris Cannam just released v1.3.0 which adds a --version option for
easy version testing [1].

[1]: https://bitbucket.org/cannam/easyhg/issue/1/teach-easymercurial-the-version-option

swc-installation-test-2.py: Initial EditorTaskDependency implementation

I'm not sold on this idea...

swc-installation-test-2.py: Add PathCommandDependency

OS X doesn't believe in $PATH ;).  Work around this heresy by simply
checking for the existence of a characteristic file or directory
(e.g. /Applications/SomeApp.app).  I use the new class to add 'xcode',
'sublime-text', 'textmate', and 'textwrangler' installations.

The location of the Xcode installation depends on your version of OS
X, and the 'xcode' comments show which path is expected for which
version.

swc-installation-test-2.py: Add TornadoPythonPackage for version extraction

Tornado follows Python's example with tornado.version and
tornado.version_info instead of using tornado.__version__.  While we
could parse tornado.version with our usual machinery, take advantage
of the pre-parsed version_info by defining a new class.

swc-installation-test-2.py: Add long names for virtual-* packages

Give a more user-friendly description of what we're checking for.

swc-installation-test-2.py: List all causes for or-dependency errors

Also make the and-dependency and or-dependency messages more friendly.

swc-installation-test-2.py: Add IPython notebook dependencies

You can get a successful IPython import even if you haven't installed
the dependencies you need for viewing notebooks.  This adds explicit
dependencies based on the current listings in IPython's setup.py.

swc-installation-test-2.py: Print full DependencyError chain

If a requirement is not satisfied due to an and_dependency or
or_dependency failure, raise a new DependencyError and attach the
original error as its cause (this would be easier if we didn't have to
preserve Python 2.x support).  This way we can print the whole chain
(e.g. virtual-shell failed because sh is not installed), instead of
just the lowest level error.

Also indent the messages, because:

  check for virtual-editor failed:
    or-dependency not satisfied for virtual-editor
    For instructions on installing an up-to-date version, see
    http://software-carpentry.org/setup/
    cause:
    check for Notepad++ (notepad++) failed:
      could not find 'notepad++' executable
      For instructions on installing an up-to-date version, see
      http://software-carpentry.org/setup/

is more readable than:

  check for virtual-editor failed:
  or-dependency not satisfied for virtual-editor
  For instructions on installing an up-to-date version, see
  http://software-carpentry.org/setup/
  cause:
  check for Notepad++ (notepad++) failed:
  could not find 'notepad++' executable
  For instructions on installing an up-to-date version, see
  http://software-carpentry.org/setup/

swc-installation-test-2.py: Add and_dependencies to Python package setup

Not used by any packages yet, but I'm about to use it for IPython.

swc-installation-test-2.py: Add gedit to virtual-editor

For Gnome users.

swc-installation-test-2.py: Add Pandas (pandas) >= 0.8

It's being used in 2013-01-columbia.

swc-installation-test-2.py: Handle unparsable versions gracefully

This avoids raising NotImplementedError from my IPython 0.14.dev.  We
don't want to have to start ranking alpha, beta, dev, r6, etc., so
just print the unparsable version and minimum version, and leave it to
the student to decide if their version satisfies the condition.  It's
unlikely that students have such pre-/post-release software installed
anyway.

swc-installation-test-2.py: Add ipython (script) >= 0.13

And make sure the IPython package has the same minimum version.
IPython 0.12 can't display more recent notebooks.

setup/README.md: Install-testing script care and feeding

setup: Move installation test scripts under setup/

There will be a lot of other stuff in the boot camp repository.  Stay
organized by keeping "how to set up and test your machine" stuff in a
subdirectory.

swc-installation-test-2.py: Comment out 'mercurial' dependency

There can be trouble detecting the Python package, especially on MS
Windows where the installed version of Python used to run the script
may not know about installed version of Mercurial.  Because nobody is
likely to use Mercurial's Python interface in a SWC class (they'll
probably stick to the command line interface), comment out this
dependency.

swc-installation-test-2.py: Add 'virtual-pypi-installer' and 'pip'

Students who need a Python Package Index (PyPI) installer should be
fine with either easy_install or pip [1].

[1]: http://pypi.python.org/pypi/pip
     http://www.pip-installer.org/

swc-installation-test: Return 1 on failure

I doubt anyone will check the exit status for these scripts, but it's
still good to follow conventions.

swc-installation-test-2.py: Better error message for unknown checks

swc-installation-test-2.py: Document command line arguments

swc-installation-test-2.py: Add MakeDependency class

On the fairly ancient SunOS 5.10 (January 2005), `make` doesn't
support `--version`.  Looking into the POSIX.2 specs [1], it doesn't
have to.  On FreeBSD [2] and in GNU Make [3], there is a MAKE_VERSION
variable, and the Sun executable has something similar:

  $ strings make | grep MAKE_VERSION
  .MAKE_VERSION

but it just expands to an empty string.

Since reading a makefile from stdin *is* in POSIX [1], we can use that
to test `make` if `make --version` fails.  If we get something for
MAKE_VERSION, use that.  If we get something for MAKE (required by
POSIX [2]), then call that a valid, but unkown, version.

[1]: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_04
[2]: http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/222214.html
[3]: http://www.gnu.org/software/make/manual/html_node/Features.html#index-MAKE_005fVERSION-1021
[4]: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_08

swc-installation-test-2.py: Add CommandDependency.stdin

I'm about to implement a version check for 'make' where I want to pass
a test Makefile in via stdin.

swc-installation-test-2.py: Convert .version_option to .version_options

I'm about to implement a version check for 'make' where a single
option doesn't cut it.  For version of Python before 3.3,
shlex.quote() doesn't exist [1], so use pipes.quote() instead [2].

[1]: http://docs.python.org/3/library/shlex.html#shlex.quote
[2]: http://bugs.python.org/issue9723

swc-installation-test-2.py: Add OS-version detection

Using assorted functions from the `platform` module.  On my Linux box:

  $ python2.7
  Python 2.7.3 (default, Dec  5 2012, 10:56:01)
  [GCC 4.5.4] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.linux_distribution()
  ('Gentoo Base System', '2.1', '')
  >>> platform.mac_ver()
  ('', ('', '', ''), '')
  >>> platform.win32_ver()
  ('', '', '', '')

On an OS X box:

  $ python2.6
  Python 2.6.1 (r261:67515, Aug  2 2010, 20:10:18)
  [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.linux_distribution()
  ('', '', '')
  >>> platform.mac_ver()
  ('10.6.8', ('', '', ''), 'i386')
  >>> platform.win32_ver()
  ('', '', '', '')

I don't have access to an MS Windows box, but presumably it returns
something like:

  >>> platform.linux_distribution()
  ('', '', '')
  >>> platform.mac_ver()
  ('', ('', '', ''), '')
  >>> platform.win32_ver()
  ('XP', '5.1.2600', 'SP2', 'Multiprocessor Free')

We only want to print the one that applies (e.g. don't print a
'linux_distribution' entry on OS X), so we skip entries where value[0]
is an empty string.

swc-installation-test-2.py: Use the more portable platform.uname()

From the docs [1,2]:

  platform.uname():
    Fairly portable uname interface...  Entries which cannot be
    determined are set to ''.

  os.uname():
    ... Availability: recent flavors of Unix.

[1]: http://docs.python.org/2/library/platform.html#platform.uname
[2]: http://docs.python.org/2/library/os.html#os.uname

swc-installation-test-2.py: Isolate system-info indent in _print_info

This way shifting the indents if you add a longer key is a single-line
operation.

swc-installation-test-1.py: Give instructions for 'python command not found'

swc-installation-test-2.py: Sort shells in order of preference

Placing the often-symlinked `sh` at the end of the list.  This way if
a user has Bash installed, it doesn't show up as plain old Bourne.

swc-installation-test-2.py: Break after first successful or-dependency

No need to test the other dependencies once you find one that matches.

swc-installation-test-2.py: Give suggested install hints

I can't give package-specific links yet, but they will hopefully be in
place soon.  I made the "email your instructor" suggestion optional,
because it is easy for me to imagine a course large enough that the
instructor could not field all requests.  To disable, change

  print_suggestions(instructor_fallback=True)

to

  print_suggestions(instructor_fallback=False)

swc-installation-test-1.py: Give suggested install hints

This can link to the "howto setup Python" notes from SWC once those
get a more precise link than:

  http://software-carpentry.org/setup/

swc-installation-test-2.py: Don't say how to get a terminal

We already told them how to do this in swc-installation-test-1.py,
hopefully they remember ;).

swc-installation-test-2.py: Avoid BaseException.message warning

Dodge the logic which (at least in Python 2.6.1) raises:

  DeprecationWarning: BaseException.message has been deprecated as of Python 2.6

We're setting the .message attribute explicitly, so the deprecation
warning does not apply to us.  The fix was suggested by Brett Cannon:

On Sun Jul 8 02:42:18 CEST 2007, Brett Cannon wrote [1]:
> You can get around this easily enough with a subclass that uses a
> property for message::
>
>   class gerror(Exception):
>     def _get_message(self, message): return self._message
>     def _set_message(self, message): self._message = message
>     message = property(_get_message, _set_message)

[1]: http://mail.python.org/pipermail/python-dev/2007-July/073777.html

swc-installation-test-2.py: Only require Git >= 1.7 (not >= 1.8)

Xcode 4.0.2 for OS X 10.6.8 shipped with Git 1.7.3.4.

swc-installation-test-2.py: Add EasyInstallDependency class

Distribute's easy_install supports --version (at least since 0.6.21),
but Setuptool's original version does not (at least as of 0.6c9).
Assume that if we get some kind of reasonable output from
`easy_install --version` we're dealing with the Setuptools version.

swc-installation-test-2.py: Add a virtual-shell and non-Bash shells

Commit to POSIX.2 [1] compatibility by allowing additional shells.  If
anyone has something besides sh, bash, or dash installed, they
probably know how to use it ;).

[1]: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
     IEEE Std 1003.2-1992

swc-installation-test-2.py: Don't require a specific Bash version

I have access to a machine running OS X 10.6.8, which has:

  $ bash --version
  GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
  Copyright (C) 2007 Free Software Foundation, Inc.

That means no associative arrays, but for SWC purposes, it should
still get the job done.  All we really need is POSIX.2.

swc-installation-test-2.py: Fix version extraction for sqlite3-python

The 'sqlite3' package has the same version as the standard library.
We only check for it because sometimes (e.g. on Gentoo) Python may be
compiled without this package.

swc-installation-test-2.py: Fix 'mercurial' version extraction

The Mercurial Python package stores its version in strange places.

swc-installation-test-2.py: Refactor PythonPackageDependency._get_version

Split it into pieces for easier subclassing.

swc-installation-test-2.py: Add import_module for older Pythons

importlib is new in Python 2.7 / 3.1.  Add a minimal workaround for
earlier versions.

swc-installation-test-2.py: Don't parse missing versions

swc-installation-test-2.py: import print_function for Python 2.6

Otherwise `print()` actually prints `()`, where we want it to print a
blank line.

swc-installation-test-2.py: Don't chain exceptions (yet)

Exception chaining (PEP 3134, 'raise ... from') raises SyntaxErros in
Python 2.x.  Comment the chaining out until SWC starts teaching only
Python 3.x.

swc-installation-test-2.py: Print successfully-found versions

This makes it easy to see what a user has installed.

swc-installation-test-2.py: Don't print duplicate exceptions

For example, if you have an outdated 'python', you only want to hear
about that once, not once for each PythonPackageDependency.

swc-installation-test-2.py: Cache check errors

Avoid running the same check (e.g. 'python') over and over.

swc-installation-test-2.py: `PythonDependency`s should depend on Python

swc-installation-test-2.py: Add exe_extension for MS Windows compat.

Use distutils' new_compiler() to get the appropriate exe_extension for
the user's system.  This way command names can always be specified in
their bare form, and we'll automatically add the right executable
extension for other platforms.

swc-installation-test-2.py: Add virtual-editor and virtual-browser

Often we don't care which editor is installed, so long as at least one
is installed.  This commit tweaks Dependency and adds a
VirtualDependency class to support such virtual dependencies.  You
can't get very fancy with boolean logic, but an all-and and all-or
lists will probably be sufficient for our needs.

swc-installation-test-2.py: Add some editors and browsers

Based on a list of possibilities mentioned by Cait Pickens in an
internal email.

swc-installation-test-2.py: sort CHECKS into topics

swc-installation-test: Consolidate and reorganize test scripts

Merge Konrad Hinsen and Fernando Perez's installation-testing scripts

workshop_checklist.py: Add installation-testing script

This script was linked to by Eric Bray [1] and hosted on Fernando
Perez's website [2].

[1]: https://github.com/swcarpentry/website/issues/38#issuecomment-11386945
[2]: http://fperez.org/py4science/workshop_checklist.py

swc-installation-test.py: Add installation-testing script

The content of this script was posted by Greg Wilson and attributed to
Konrad Hinsen [1].

[1]: https://github.com/swcarpentry/website/issues/38#issuecomment-11189525