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: 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
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
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.
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.