Merge branch 'python'

Significant changes:
* Bump version to 0.2
* Install GNU Make (cherry-picked from the msysGit repository)
* Mention that R should be installed before running our installer

* python:
  swc-windows-installer.py: Bump version to 0.2
  swc-windows-installer.py: Fix "it's hash" -> "its hash" typo
  swc-windows-installer.py: Add install_msysgit_binary and install Make
  swc-windows-installer.py: Add a trailing paren to get_r_bin_directory.__doc__
  Replace 'Anaconda CE' -> 'Anaconda'
  Mention that R should be installed before running our installer

Conflicts:
README.md (due to different usage instructions between the Python
  branch and the Inno branch).

swc-windows-installer.py: Bump version to 0.2

Changes since v0.1:
* Install GNU Make (cherry-picked from the msysGit repository).
* Mention that R should be installed before running our installer.
* Fix some typos in docs and docstrings.

swc-windows-installer.py: Fix "it's hash" -> "its hash" typo

Reported-by: Steve Haddock <haddock@mbari.org>

Merge pull request #21 from wking/make

swc-windows-installer.py: Add install_msysgit_binary and install Make

swc-windows-installer.py: Add install_msysgit_binary and install Make

The whole msysGit dev environment is large [1]:

  On Fri, Jun 13, 2014 at 01:22:01AM -0700, Mike Jackson wrote:
  > Disk space is cheap but 2GB is still a big ask - attendees laptops
  > can be quite old and limited in terms of space.

And may be more difficult to install than the Git for Windows
packaging [2]:

  On Fri, Aug 15, 2014 at 12:46:21PM -0700, Ethan White wrote:
  > My concern with installing msysGit is that the installer process
  > was substantially more complicated (at least the last time I
  > looked 6-12 months ago). My concern is that folks will get hung up
  > on all of the options and at best feel confused/overwhelmed and at
  > worse not end up with a working install.

Since that simple option (replace Git for Windows with the full
msysGit) isn't available, with this commit we just grab the Make
executable from the msysGit repository.  To make grabbing additional
binaries easier, I've implemented this with the generic
install_msysgit_binary.  I've also pinned the download to the most
recent tag (Git-1.9.4-preview20140815), to keep the sha1 from changing
under our feet.  However, the make.exe binary was last touched on
2012-01-26 [3] and the last hash-changing commit was on 2007-08-06
[4], so it's not exactly a high-churn target ;).

It would be nice if Windows came with a package manager (or even if
msysGit was compatible with the upstream MSYS [5]) so we didn't have
to jump through all these hoops.

[1]: https://github.com/swcarpentry/bc/pull/533#issuecomment-45986839
[2]: https://github.com/swcarpentry/windows-installer/issues/6#issuecomment-52349647
[3]: https://github.com/msysgit/msysgit/commit/cb9836b8a5ea9aa8f2cb7a373e58eeb6c000d4a7
[4]: https://github.com/msysgit/msysgit/commit/2914373028897add73217340e515f5d69d7dd027
[5]: http://thread.gmane.org/gmane.comp.version-control.git/246514/focus=20055
     Subject: Re: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
     From: Heiko Voigt <hvoigt@hvoigt.net>
     Date: 2014-04-19 18:42:10 GMT
     part of a thread started with [6].
[6]: http://thread.gmane.org/gmane.comp.version-control.git/245734
     Subject: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
     From: Marat Radchenko <marat@slonopotamus.org>
     Date: 2014-04-03 13:18:50 GMT

swc-windows-installer.py: Add a trailing paren to get_r_bin_directory.__doc__

Fix a typo from 58b7183e (swc-windows-installer.py: Look for an R bin
directory, 2014-06-09).

Replace 'Anaconda CE' -> 'Anaconda'

On 2013-03-13, Continuum dropped the CE and made 'Anaconda' free [1].

[1]: http://continuum.io/blog/anaconda-1-4-released

Mention that R should be installed before running our installer

This came up in response to the v0.1 release announcement on
discuss@lists.software-carpentry.org [1].

[1]: http://lists.software-carpentry.org/pipermail/discuss_lists.software-carpentry.org/2014-August/001932.html

Merge pull request #14 from wking/latest-release

README.md: Link to GitHub releases for the most-recent compiled version

Merge pull request #15 from wking/r-instructions

README.md: Mention that R should be installed before running our installer

README.md: Mention that R should be installed before running our installer

This came up in response to the v0.1 release announcement on
discuss@lists.software-carpentry.org [1].

I've also added a link to Python (and used it where we mention Python)
to match the existing link to R.

[1]: http://lists.software-carpentry.org/pipermail/discuss_lists.software-carpentry.org/2014-August/001932.html

Reported-by: John Blischak <jdblischak@uchicago.edu>

README.md: Link to GitHub releases for the most-recent compiled version

This way we don't need to remember to push to
files.software-carpentry.org.  The linked page has the message from
the latest release and a link to the exectuable, when it used to be
just the exectuable.  A quick search didn't turn up a way to link
directly to the latest binary.  I'm not particularly worried about the
additional click though, and folks working up installation
instructions for a given workshop should probably be linking to an
explicit version anyway.

Merge branch 'python' for release 0.1

swc-windows-installer.py: Add --version and start with 0.1

Since we're decoupling these scripts (and any installers derived from
them) from the per-workshop repository, it's good to have an easy way
for folks to see which version they're dealing with.

swc-windows-installer.py: Search ProgramW6432 and ProgramFiles(x86)

It turns out that the 'ProgramFiles' environment variable is set
differently depending on the architecture of process in question.  To
always get the 32-bit x86 version, you should use 'ProgramFiles(x86)'
[1].  To always get the 64-bit amd64 version, you should use
'ProgramW6432' [2].

To be safe, and support both 32- and 64-bit Windows installs, just
search everything that could be relevant.  Prefer 64-bit locations
(when we have any).

[1]: http://technet.microsoft.com/en-us/library/cc749104%28v=ws.10%29.aspx
     Recognized Environment Variables
     ...
     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.

[2]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384274%28v=vs.85%29.aspx#Environment_Variables
     WOW64 Implementation Details
     ...
     64-bit process:
        ProgramFiles=%ProgramFiles%
        ProgramW6432=%ProgramFiles%
     32-bit process:
        ProgramFiles=%ProgramFiles(x86)%
        ProgramW6432=%ProgramFiles%

     The ProgramW6432 and CommonProgramW6432 environment variables
     were added starting with Windows 7 and Windows Server 2008 R2.

swc-windows-installer.py: Add missing space to 'c:\ProgramFiles'

This is the default for when ProgramFiles isn't set.  Windows
operating systems should always have that environment variable set, so
the default is probably only useful when you're testing the script on
a non-Windows system.

swc-windows-installer.py: Set default logging level to INFO

And add the other levels as --verbose choices, even though we
currently only use LOG.info and LOG.debug.  Many *nix commands are
silent by default and have options for increasing the verbosity, but
Ethan points out that we should probably default to the setting that
makes the most sense for new users.

Add build instructions for Inno installer

Merge branch 'python'

I'd usually wait for more interesting changes to queue up, but this
should help demonstrate my intended release process.

* python:
  Fix 'Add' -> 'Adds' to match 'The script' lead-in

Fix 'Add' -> 'Adds' to match 'The script' lead-in

"The script adds ..." reads better.

README.md: Update usage for folks running the compiled installer

With the Inno installer, there's no need to download Python or msysGit
ahead of time.  Also, folks who aren't building their own installer
can use the latest compiled release.  I'm not sure how the compilation
process works, so I'll leave that for Ethan to fill in.

Once we're actually tagging releases here, we'll probably be linking
to GitHub's releases [1] instead of files.sw-c.org, but we haven't
tagged a release yet.

[1]: https://github.com/swcarpentry/windows-installer/releases

Merge branch 'python'

Pull in recent changes to the install script, especially the license
and README (now that we're a stand-alone repository).

* python:
  README.md: Copy the docstring into a README
  swc-windows-installer.py: Fix 'swc_windows_installer.py' -> hyphens
  swc-windows-installer.py: Change '~/nano.rc' to 'a ~/nano.rc'
  swc-windows-installer.py: Canonical SQLite capitalization
  COPYING: Add the full text of the MIT license

README.md: Copy the docstring into a README

And add Markdown links for all the packages we reference.  This gives
folks hitting the repository a more traditional welcome.

swc-windows-installer.py: Fix 'swc_windows_installer.py' -> hyphens

Match our local script name in the instruction comment.

swc-windows-installer.py: Change '~/nano.rc' to 'a ~/nano.rc'

I think the comment reads more clearly with the article.

swc-windows-installer.py: Canonical SQLite capitalization

We might as well match the upstream capitalization conventions.

COPYING: Add the full text of the MIT license

Downloaded from http://opensource.org/licenses/mit-license.html, with
the year from our first commit and a generic author identifier.  For a
full list of copyright holders, see the version control history.

Add a Software Carpentry icon file for Windows installer

Add script for building Windows installer

This script tells Inno Setup how to build the stand alone installer

Add setup.py file for building Windows installer

This setup.py file allows building an executable version of the
installer that doesn't require an external Python installation.

swc-windows-installer.py: Add logging

The more light we can shine on the process, the more accessible it
will be to the students :).  And the easier it will be to debug for
the helpers ;).

swc-windows-installer.py: Link to msysGit releases on GitHub

I think this is the last bit of the old Google Code infrastructure
that was left to transition.

swc-windows-installer.py: Standardize on 'msysGit' capitalization

That's what the project uses for itself.

swc-windows-installer.py: Look for an R bin directory

On Thu, May 15, 2014 at 08:07:19PM -0700, Ethan White wrote:
> Problem: R is not added to the Windows' path when it is
> installed. This means that any workshops that use R from the command
> line will run into problems (as we did at the first Data Carpentry
> workshop).
>
> Solution: Add R to the path using our Windows' installer.
>
> Challenges: Just to make @wking's life exciting, R's path varies
> depending on the version. The standard path is `C:\Program
> Files\R\R-x.x.x\bin\` where `x.x.x` is the version number of the
> installed version of R.

Add indication that the Windows installer is running

The Windows installer opens a shell while running. This adds some
text to that shell so that it is clear that something is happening.

swc-windows-installer.py: Install the sqlite3 shell

On Thu, Apr 03, 2014 at 09:38:38AM -0700, Ethan White wrote:
> Some instructors like to teach `sqlite` from the command
> line. Therefore we should have the Windows installer handle
> downloading, installing and adding sqlite3 to the path.

The novice/sql lessons currently revolve around some IPython magic,
but even they use the SQLite shell to do the initial database setup
[1].  The SQLite shell has also seen a bit more developer time than
our one-off magic [2], so it's probably more robust ;).

I've installed this in it's own directory (rather than just dumping it
into ~/.swc/bin), because zip_install uses the existence of
${INSTALL_DIRECTORY} to decide whether or not the installation has
already happened.  create_nosetests_entry_point will have already
created ${BIN_DIR}, so we need to use a different target directory for
SQLite.  We could also flip the order and run install_sqlite first,
but that doesn't scale well if we install more packages in the future,
and it's easier to keep the installs separate and keep adding to the
path.

[1]: https://github.com/swcarpentry/bc/blob/1aa0799ac6a48e9815d50bf2f49171b9eb5bf6d4/novice/sql/README.txt#L8
[2]: https://github.com/swcarpentry/bc/blob/1aa0799ac6a48e9815d50bf2f49171b9eb5bf6d4/novice/sql/sqlitemagic.py

swc-windows-installer.py: Generalize msysGit download link

SWC's current setup instructions use both "Git for Windows" and "Git
Bash" [1].  They link to the Git for Windows installer [2] and not the
msysGit installer [3].  Since SWC has Make lessons [4], I think it
makes more sense to have students installing msysGit (which has Make
[5]) than to have them install Git for Windows (which does not have
Make [6]).

However, none of this matters for *this* Windows installer.  Because
this script works with both the full msysGit and the minimal Git for
Windows, I'm sticking to msysGit (the more generic project name), and
generalizing the suggested link to
http://code.google.com/p/msysgit/downloads/list.

[1]: https://github.com/swcarpentry/bc/blob/5c26313b0525e9d0b911d9558592a9e33cd03c1e/_includes/setup.html#L86
[2]: http://code.google.com/p/msysgit/downloads/list?q=full+installer+official+git
[3]: http://code.google.com/p/msysgit/downloads/list?q=installer+hack+on+git
[4]: https://github.com/swcarpentry/bc/tree/master/intermediate/make
[5]: https://github.com/msysgit/msysgit#the-build-environment
[6]: https://github.com/msysgit/msysgit#the-relationship-between-msysgit-and-git-for-windows

swc-windows-installer.py: Force UNIX-style \n line endings for ~/nano.rc

On Thu, Mar 13, 2014 at 03:37:12AM -0700, Ethan White wrote [1]:
> We now have a line ending issue resulting in:
>
>     Error reading /cygdrive/c/Users/...
>
> This is fixed by running `dos2unix` on the resulting nano.rc.

This is also mentioned in the nano FAQ [2]:

> Note that the nano.rc file must remain Unix formated in order for
> nano to unerstand it.

Since Python 3.0 and PEP 3116, Python's open() has taken a 'newline'
argument that allows you to override the default line separator for a
particular file [3,4].  However, Python 2.x does not support that
argument [5].  This commit adds a local 'open3' which uses a terrible
hack of a wrapper on Python 2 to fake that support.  It opens the file
in binary mode, and takes advantage of Python 2's lack of distinction
between str and bytes to treat the \n-terminated strings as the raw
binary output.  That's going to crash and burn if you have any
non-ASCII characters in the output content, but we explicitly set all
the components in our relative include_path, so that shouldn't be a
problem.

Another side effect of binary-mode is that we are going to get
ASCII-encoded output, not output encoded in the user's preferred
encoding (locale.getpreferredencoding [3,6]).  That's unfortunate,
because nano does the right thing and uses your locale to decode input
(at least for UTF-8 locales [7], presumably including your nano.rc
file).

[1]: https://github.com/swcarpentry/bc/pull/357#issuecomment-37518899
[2]: http://www.nano-editor.org/dist/v2.2/faq.html#3.9.1
[3]: http://docs.python.org/3/library/functions.html#open
[4]: http://legacy.python.org/dev/peps/pep-3116/
[5]: http://docs.python.org/2/library/functions.html#open
[6]: http://docs.python.org/2/library/stdtypes.html#file.encoding
[7]: http://www.nano-editor.org/dist/v2.2/faq.html#5.3

swc-windows-installer.py: Use POSIX paths for ~/nano.rc

On Wed, Mar 12, 2014 at 06:34:43PM -0700, Ethan White wrote [1]:
> The bash script in #228 is now working properly, but the Python
> script is still failing. It reports errors like:
>
>     Error reading ~\.swc\share\nanorc\doc\syntax\python.nanorc
>
> The obvious difference is that the nano.rc files produced by the
> bash script have `/` for paths for the includes, but the Python
> script produces includes that use `\`.

[1]: https://github.com/swcarpentry/bc/pull/357#issuecomment-37491038

swc-windows-installer.py: Use '~' in ~/nano.rc includes

On Wed, Mar 12, 2014 at 04:44:31PM -0700, Ethan White wrote [1]:
> Got it. We just need to change the `/c/Users/River/` in the include
> statements to `~/` and everything works great!

[1]: https://github.com/swcarpentry/bc/pull/357#issuecomment-37483149

swc-windows-installer.py: Rename ~/.nanorc to ~/nano.rc

The nano FAQ hints that this is the prefered path on MS Windows [1],
and Ethan White confirmed it in testing [2].

[1]: http://www.nano-editor.org/dist/v2.2/faq.html#3.9.1
[2]: https://github.com/swcarpentry/bc/pull/357#issuecomment-37482899

swc-windows-installer.py: Install nano source syntax highlighters

Make writing Python source code (and a number of other languages) a
bit more exciting for the eyes and easier on the brain by coloring
strings, comments, and such.

We need to install the source tarball because the compiled zip doesn't
include the syntax highlighting scripts.  To make that easier, I've
extracted out the download / hash-check functionality into a new
download(), which I use in both the old zip_install() and the new
tar_install().  If the user doesn't have an existing ~/.nanorc, we
populate it by adding 'include' options for each of the syntax files
in the Nano tarball.  If they do have an existing ~/.nanorc, I assume
they know what they're doing ;).

The default '*' compression is for transparent detection [1], but you
can override it to explicitly select the compression type if you like.

There's a bit of ugliness to work around the lack of a
--strip-components analog in TarFile.extractall [2].  Instead, we
iterate over the TarInfo members and strip leading components from
their 'name' by hand [3].

[1]: http://docs.python.org/3/library/tarfile.html#tarfile.open
[2]: http://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall
[3]: http://docs.python.org/3/library/tarfile.html#tarfile.TarInfo.name

swc-windows-installer.py: Quote $PATH export to account for spaces.

Many people have spaces in their Windows user names, leading to
trouble with an unquoted $PATH export.  This file now quotes the $PATH
addition accordingly.

swc-windows-installer.py: Use regular expressions to POSIX-ify paths

On a Windows 7 SP1 box with Python 2.7.3:

  >>> import os.path
  >>> os.path.expanduser('~')
  'c:/Users/JohnDoe'

That wasn't matching the previous POSIX-ification patterns, which
assumed the drive prefix would be uppercase (C:).  Now we use a
regular expression to match both cases.

swc-windows-installer.py: Only create the python-scripts dir if it doesn't exist

os.makedirs, unlike 'mkdir -p', errors if the target directory already
exists [1,2].

[1]: http://docs.python.org/2/library/os.html#os.makedirs
     "Raises an error exception if the leaf directory already exists
     or cannot be created"
[2]: http://docs.python.org/3/library/os.html#os.makedirs
     "If exist_ok is False (the default), an OSError is raised if the
     target directory already exists."

swc-windows-installer.py: Split out zip_install into its own function

This makes it easy to install other packages besides nano.  I've also
added SHA1 checks to avoid installing packages that don't match the
expected hash.  This lets us trust ZipFile.extractall instead of
extracting from a hard-coded list of approved files.

swc-windows-installer.py: Restore nose entry point

This restores the nose entry point which was removed in 94caead
(swc-windows-installer.py: Remove IPython and nose entry points,
2013-10-21).

On Tue, Oct 22, 2013 at 11:36:21AM -0700, Ethan White wrote:
> IPython works fine for me on Windows 7 for both Anaconda and Canopy
> with no added entry points needed.
>
> Nosetests does not appear to have an entry point on Anaconda and I
> forgot to test it with Canopy.

I used a slightly different bin path than we'd used previously, to
respect 806fedf (swc-windows-installer.py: Rework install paths to use
~/.swc, 2013-10-21).

swc-windows-installer.py: 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-nano-installer.py: Remove now that changes are in swc-windows-installer.py

swc-windows-installer.py: Rework install paths to use ~/.swc

Instead of cluttering the user's home directory with multiple
SWC-installed directories, reduce clutter and improve namespacing by
dumping everything inside ~/.swc.  Think of it as a SWC-specific
~/.local.  We avoid actually using ~/.local because users might
already be using that for other purposes.

Use os.makedirs to create the nano install directory if it does not
already exist, because ZipFile.extract uses os.mkdir internally, and
mkdir will not recursively create directories.

swc-windows-installer.py: Remove IPython and nose entry points

Ethan thought these had been fixed upstream, and Aron Ahmadia pointed
to the Anaconda v1.6.2 release notes [1]:

  2013-07-09: 1.6.2: (Windows only)

    Fixed path being incorrectly appended on Windows during install

That means we can drop our entry point scripts and fall back to just
installing Nano and setting up EDITOR.

[1]: http://docs.continuum.io/anaconda/changelog.html

swc-windows-installer.py: De-emphasize Anaconda

Bridge the gap between the original Anaconda plug and Ethan's simpler
"Install Python" from 833d0ee (Add a Nano installer for Windows,
2013-09-17).  As of Anaconda 1.7.0, IPython 1.0.0 and nose 1.3.0 are
included by default [1].

[1]: http://docs.continuum.io/anaconda/pkgs.html

swc-windows-installer.py: Rework paths in main()

Based on Ethan's path handling in 833d0ee (Add a Nano installer for
Windows, 2013-09-17), while still retaining the entry-point creation
for IPython and nose.

swc-windows-installer.py: Generalize update_bash_profile

And rename from make_bash_profile now that we're appending instead of
creating (since c5d5414, Append exports to end of .bash_profile
instead of overwriting, 2013-09-19).

This more general form can be used to add even more paths, for example
our IPython and nosetest entry points.

swc-windows-installer.py: Bring in Ethan's make_bash_profile and make_posix_path

This integerates some of Ethan's nano-installer changes.  In the pull
request, Ethan elaborates on the .bash_profile choice [1]:

  In response to comments on the Tutors list the installer now uses
  .bash_profile instead of .bashrc and appends the lines rather than
  overwriting the file. I have also added comments that indicate where
  the new lines in .bash_profile come from.

  Once the Python version is in I'll move on to getting this compiled
  into a .exe file, which should be more familiar to our students and
  won't run into issues with Canopy installs opening the file in
  Canopy rather than executing it.

The referenced tutors@ discussion is in the messages leading up to
[2], where Ethan top-quotes a discussion with R. David Murray about
the relative merits of .bash_profile and .bashrc.  The imporant point
David made was that .bash_profile is only executed once at login,
while .bashrc is executed for each new shell.  Putting PATH appends in
.bash_profile means that you don't end up adding duplicate entries to
the PATH as you spawn subshells.  For example:

  ${ORIGINAL_PATH}:${NANO_PATH}:${NANO_PATH}:...

[1]: https://github.com/swcarpentry/bc/pull/35
[2]: http://lists.software-carpentry.org/pipermail/tutors_lists.software-carpentry.org/2013-September/000969.html

Merge branch 'nano-installer' into windows-installer

* nano-installer:
  Remove testing line
  Append exports to end of .bash_profile instead of overwriting
  Switch from using .bashrc to .bash_profile nano path and editor export
  Add a Nano installer for Windows

Remove testing line

Append exports to end of .bash_profile instead of overwriting

In the process at an explanation of where the lines came from
so that users know they can remove the lines if desired.

Switch from using .bashrc to .bash_profile nano path and editor export

Add a Nano installer for Windows

1. Downloads and installs Nano into the users home directory
2. Adds Nano to the path
3. Makes Nano the default editor

swc-windows-installer.py: Use the stdlib's urlopen()

This way I can test the script (on Linux, but whatever) without having
to install an additional package.

swc-windows-installer.py: Use lists for file content

This allows us to keep the usual Python block indentation while still
producing the appropriate wrapper content.

swc-windows-installer.py: Use `with` to write script wrappers

From PEP 343.  This gives you automatic file descriptor (file handles
on Windows?) cleanup on errors.  Also use os.path.join() to build the
paths.

[1]: http://www.python.org/dev/peps/pep-0343/

swc-windows-installer.py: Simplify `ipython` wrapper

This matches my system's `/usr/bin/ipython-2.7`, and is the hook
defined in IPython's setupbase.py:

  'ipython%s = IPython.frontend.terminal.ipapp:launch_new_instance'

This should handle the 'notebook' option internally.

swc-windows-installer.py: Extract nano directly to the install directory

This is more efficient than "extract to . and then copy".  I also
renamed the install_nano() argument.  The function doesn't care that
we're currently passing the Python script directory; it will work
perfectly well with a different directory in the PATH.

swc-windows-installer.py: Avoid writing nano.zip to disk

It's already in memory, and we're going to use it again immediately.
Avoiding the flush-to-disk is both more efficient, and easier to clean
up.

swc-windows-installer.py: Separate requests import from stdlib imports

Python-requests [1] is not part of the stdlib.

[1]: http://docs.python-requests.org/en/latest/

swc-windows-installer.py: Cleanup whitespace

swc-windows-installer.py: Setup msysgit to act like *nix systems

* Install `nano` 2.2.6.
* Add `ipython` and `nosetests` command line entry points.