Best strategies for Windows installation

[tracykteal]

If you've been teaching, how have you been handling installation for Windows? Have you been using the SWC Windows installer? If so, what has your experience been or if you haven't what have you been doing instead?

Comment here and take this quick poll

Software Carpentry Windows installation poll: https://tinyurl.com/swc-windows-install

[naupaka]

We just had a SWC workshop this past weekend and a faculty member did not come back on the second day over frustration with hours spent trying to get nano installed on the first day. I should have thought more quickly and recommended notepad myfile.txt sooner (was teaching and didn't realize what was going on).

[fmichonneau]

In the last SWC workshop I was involved with (more than 6 month ago), there were some issues with not finding nano after using the Windows installer. We suggested participants used RStudio as their text editor. They had it already installed given it was a R-flavored workshop.

[noamross]

I have always used the windows installer because I'm not familiar with windows and thought it was the default, but almost always have install issues with the majority of windows users. In my last workshop I was able to get them using notepad when nano failed and it worked ok despite line-end issues.

I think we should seriously consider using Atom as the teaching editor. Yes, it makes for multiple-window issues in teaching, but learners using Notepad or Notepad++ will have multiple windows, too, and multiple windows are really a more realistic working environment for most people. As said on the listserv, this is a teaching opportunity to show how the shell and the GUI file system interact, and Atom can also be configured as a default git editor.

I note that upcoming releases of RStudio will have a built-in terminal window and will allow users to use the RStudio text editor as a default git text editor. This should work across platforms but I don't know if RStudio will run git-bash or some other non-default shell. I have no understanding of the various windows shells.

[evanwill]

I think having a quality text editor is an essential piece of software that will serve workshop participants well to have sorted out, so I agree with @noamross suggestion that "multiple windows" is not an important issue. However, I still think Nano is very handy to have available and it would be nice to have integrated with the Windows shell.

[evanwill]

Another part of the conversation that started on the discussion list was the question of what is actually is necessary for the Windows set up. Currently the installer assumes the user installs "Git for Windows" independently, then runs the installer to add Nano, Make, and SQLite. There seems to be a lot of interest in ensuring Nano is available, but are people commonly using Make and SQLite?

[noamross]

I have never taught Make or SQLite for a workshop, but I always teach R-type workshops, so I don't know.

I just checked with the developer and the new RStudio terminal will support git-bash on Windows: https://twitter.com/GaryTRitchie/status/839969422001369089

[rgaiacs]

I never taught Make or SQLite. Most of the workshops that I taught were Python based workshops and Python is a more "powerful" tool than Make, i.e. you can do more stuffs with Python than with Make so for (beginners) learners was pointless to learn Make. I know that Make is a great tool to compile C/C++/Fortran code or to manage workflow dependencies but for most of my learners the time invest to learn Make would not payoff. About SQLite, I remember that a few learners had asked for a SQLite workshop but the number was small, less than 10%.

[naupaka]

Perhaps worth pointing out that SQLite is a core part of Data Carpentry workshops, and these are taught using the Firefox GUI SQLite plugin. In that case, I've asked Windows folks to install SQLite from the sqlite.org site directly. That's worked fine. I also think make classes are rather rare. So I think the primary and perhaps only thing we need to solve robustly is how to reliably get nano or some other text editor onto users' computers. I prefer nano to other editors for SWC because it's useful to show people how to edit text files entirely from the command line, but I also think a reliable install for workshops is even more important than that. So, if we can't get an easily maintainable way to install nano and fix its path problems in GitBash then we should seriously consider the use of something like Atom, just because it would be easier. My 2¢.

Another thought: could we convince the Git for Windows folks to add pico or nano to their installer?

[tracykteal]

Thanks for all the feedback. Here are poll results

It seems like people are using and like using the SWC Installer. The main issue that it's solving though is a text editor for gitbash, since Make and SQL aren't generally being taught in SWC. To @naupaka's point, in Data Carpentry, we do just have them use the SQLite plugin for SQL, so the installer isn't used for SQL there.

It is nice to teach nano or another command line text editor, because it's what people will see if they log onto a remote Linux computer and will likely be their only option. We want to keep having people install gitbash as their command line, because they need it anyway for the git section.

So, we need to either

1. fix the SWC installer to install nano properly
2. create a pared down SWC installer that just installs nano and sets paths
3. have the Git for Windows folks add pico or nano (has anyone filed an issue there?)
4. decide that we can't get nano to work, even though it would be nice, and have people install Atom (this is a nice cross platform tool that we could also have Mac users install)

Option 2 seems consistent with the feedback on what's needed and would likely be lower maintenance. Does that seem reasonable? Would anyone be able to write a python script that could do that, even based off the current installer code? Then I think one of the installer maintainers could turn it into an executable.

cc @embray @wking

[rgaiacs]

Option 2 seems consistent with the feedback on what's needed and would likely be lower maintenance. Does that seem reasonable? Would anyone be able to write a python script that could do that, even based off the current installer code? Then I think one of the installer maintainers could turn it into an executable.

I tested Cygwin and I didn't like the installation steps because learners will need to search for the packages and the GUI is confuse. One option is use a command line installation. If we could have an one-click installer based on Cygwin would be great.

I prefer to enforce the use of Atom during the workshop instead of rely on our own (hack) script to patch nano into Git on Windows.

[evanwill]

There is discussion about Cygwin and the SWC installer at swcarpentry/windows-installer#2

As @rgaiacs says, the Cygwin GUI installer is clunky, but using command line can be much cleaner: something like setup-x86_64.exe -q -P git,make,sqlite3 will set up the same packages are the SWC installer. However, there are concerns about the non-intuitive way Cygwin creates a new /home/user directory.

[evanwill]

Option 3. have the Git for Windows folks add pico or nano (has anyone filed an issue there?)

Combining Option 2 and 3, it looks like it would be possible to create a customized "Git for Windows" installer that includes Nano using the Git for Windows SDK, https://github.com/git-for-windows/git/wiki/Technical-overview

The git-for-windows/MSYS2-packages list includes Nano, so it seems like the code is available. Has anyone used Git for Windows SDK?

[tracykteal]

The Git for Windows SDK does looks promising! I've let the folks on the Software Carpentry Steering Committee know about this thread, so they could help come to a decision on how to proceed.

[rgaiacs]

One of the things that I shortly investigate was providing a batch script (not bash script, the one for Windows!) to download Cygwin and run it using the options that we want. But I couldn't find one way to download Cygwin .exe from the batch script.

[embray]

@rgaiacs

I tested Cygwin and I didn't like the installation steps because learners will need to search for the packages and the GUI is confuse. One option is use a command line installation. If we could have an one-click installer based on Cygwin would be great.

To be clear, a one-click installer based on Cygwin is what I've been advocating for a while. If I can have just a little more time I can make a demo soon.

[embray]

In fact, if anyone wants to try it out now, they can install my SageMath for Windows installer, the latest version of which is at: https://github.com/embray/sage-windows/releases/tag/0.1a4-7.4

It's very large and takes a long time to install, but that's because Sage itself is huge and comes with a lot of other packages and data. But ultimately all this is is a customized Cygwin install. What I have in mind for SWC would be almost exactly the same, just without Sage and its dependencies (but with Python, R, and related packages).

(Note: It's also almost entirely self-contained and can be easily uninstalled. It will just leave any config files it created in your home directory).

[k8hertweck]

I've done a bit of investigating and have determined that Git for Windows is disinclined to add nano to their main project, but an alternative is developing our own custom installation package using the Git for Windows SDK and adding the features we'd like.

@embray Is it possible to resolve the issue with Cygwin's default home directory/file structure causing paths that are confusing to new learners? I used Cygwin for a semester-long class for new programmers and this issue was incredibly difficult to manage.

[k8hertweck]

The windows installer gives learners three things: nano, sqlite, and make. An extra data point for consideration of supporting the updating of this software is that (according to our records) sqlite is only occasionally taught at workshops (and an effective alternative installation strategy is available), while make has not been taught in recent memory (e.g., 12-18 months, but please correct me if I'm wrong!).

[rgaiacs]

@k8hertweck Thanks for your investigation. I have a proof of concept in place at carpentries/workshop-template#391 that can be preview at http://rgaiacs.github.io/swc-workshop-template/. @embray I will be grateful if you could review the pull request.

[ashander]

@justbennet I think these comments would be most useful directly on the PR @rgaiacs made carpentries/workshop-template#391

[justbennet]

Apologies to all. I was perhaps misled by the comment preceding it and did not register that the conversation should move. I will repost there. I see I can delete it have done so. Sorry, again.

[embray]

@k8hertweck

Is it possible to resolve the issue with Cygwin's default home directory/file structure causing paths that are confusing to new learners? I used Cygwin for a semester-long class for new programmers and this issue was incredibly difficult to manage.

Could you say a little more about this? Are we just talking about the fact that the /home/ directory on Cygwin defaults to being under C:\cygwin\home as opposed to the user's Windows home directory?

[embray]

Here's a preview for a possible alternative to carpentries/workshop-template#391

There's no instructions yet (hence no alternative PR to workshop-template, but I can work on that). This is the "stand alone" installer I've mentioned putting together: https://github.com/embray/windows-installer/releases/tag/v0.4a0 (I'm still in the process of uploading the built executable, which is extremely slow right now for some reason)

Upsides

• All the upsides to using Cygwin that were mentioned in Replace Git Bash with Cygwin workshop-template#391
• No scripts to run or anything, just a point and click installer--no more than a few clicks
  • The point-and-click installer could display additional instructions and/or conditions; haven't done that yet
• Does not require escalated privileges--does not even invoke UAC. The installation goes into the users's profile in the standard location (C:\Users<Username>\AppData....). Includes an uninstall program.
• Self-contained. A single file download that won't require any downloads during a workshop--instructor can bring copies on USB drives, etc.
• Includes apt-cyg, however, a command-line tool for installing additional Cygwin packages; users with internet connections can install, for example, their favorite text editor
• Doesn't force the learner to learn anything about Cygwin, at least not initially. Instead creates shortcut named just "Terminal" that looks a lot like the "Terminal" icon on OSX.
• Configures Cygwin to mount the user's Windows profile as their home directory

Downsides

These are downsides to using Cygwin, regardless of how it gets installed:

• ls currently displays Windows system files that are normally hidden from the user on Windows. This is especially annoying in the home directory which shows lots of files like:

-rwx------  1 SYSTEM         SYSTEM       1835008 Nov 21 11:31  ntuser.dat.LOG1
-rwx------  1 SYSTEM         SYSTEM       2289664 Nov 21 11:31  ntuser.dat.LOG2
-rwx------  1 SYSTEM         SYSTEM         65536 Dec 15 10:38  NTUSER.DAT{5d9ec12c-afd5-11e6-b20c-b9e627ee13aa}.TM.blf
-rwx------  1 SYSTEM         SYSTEM        524288 Dec 15 10:38  NTUSER.DAT{5d9ec12c-afd5-11e6-b20c-b9e627ee13aa}.TMContainer00000000000000000001.regtrans-ms
-rwx------  1 SYSTEM         SYSTEM        524288 Nov 21 11:31  NTUSER.DAT{5d9ec12c-afd5-11e6-b20c-b9e627ee13aa}.TMContainer00000000000000000002.regtrans-ms
-rwxrwx---+ 1 SYSTEM         SYSTEM       1048576 Mar 21 10:23  NTUSER.DAT{e57057d6-bc9e-11e6-a92c-902e1c47657f}.TxR.0.regtrans-ms
-rwxrwx---+ 1 SYSTEM         SYSTEM       1048576 Mar 21 10:23  NTUSER.DAT{e57057d6-bc9e-11e6-a92c-902e1c47657f}.TxR.1.regtrans-ms
-rwxrwx---+ 1 SYSTEM         SYSTEM       1048576 Mar 21 10:23  NTUSER.DAT{e57057d6-bc9e-11e6-a92c-902e1c47657f}.TxR.2.regtrans-ms
----rwx---+ 1 Administrators SYSTEM         65536 Mar 21 10:23  NTUSER.DAT{e57057d6-bc9e-11e6-a92c-902e1c47657f}.TxR.blf

(this is an annoyance to me when I use Cygwin too; I am writing a wrapper around ls to hide these files by default)

• No clear resolution yet how to integration Python/Anaconda or R into the Cygwin terminal.
• Relatively difficult for instructors to modify / rebuild (but see below in TODO).

TODO

• Right now there's no documentation for building this installer. That won't be hard for me to fix. There's just none yet because I hacked this together as a quick demonstration (if it seems at all complicated that's only because I adapted it from my installer for SageMath which is much more complex). So I need to document how to build this, and how to modify it. In particular, it would be good if instructors can easily add additional packages.
• Make it easy to build new installers. Ideally, if instructors wanted to modify the installer, they should be able to build their own versions of it without hassle. I could an a AppVeyor build configuration for it so that instructors can fork this repo, make their modifications, and get a modified installer built by AppVeyor and delivered to them.
• Add Python, R, and Jupyter. I think I would ultimately prefer this over using Anaconda for Python. Nothing at all against Anaconda, but adding Python to the installer (through Cygwin) will integrate better with everything else, and reduce the cognitive overhead that much more (no "are you using the Anaconda Python or some other Python"--in the Cygwin environment there will just be the Python in Cygwin, much like on a Linux system). Same goes partially for plain R, but less so for R Studio which I'm not sure how to integrate, if at all.

[embray]

On the Python issue, I'm not entirely sure installing Anaconda is really necessary for sure (though I don't know how much not using Anaconda would impact the lesson material). Jupyter / IPython and the notebook work fine under Cygwin, as do most scientific Python packages that are used in the lessons (namely Numpy, scipy).

[evanwill]

Re: Anaconda Python in Cygwin issue: @rgaiacs @embray

This is an issue with the MinTTY terminal, so the same issue exists with Git Bash in my experience.
Apparently Anaconda Python doesn't correctly identify MinTTY and runs in non-interactive mode. So it is not that Anaconda Python doesn't work in the terminal, it is just not opening in interactive mode. This means you can still run a script (eg. python test.py). Further more, ipython and jupyter notebook seem to work fine.

This can be avoided by opening Cygwin or Git Bash in the Windows cmd.exe terminal. On Cygwin this is done by running C:\cygwin64\Cygwin.bat. Anaconda Python then works correctly. For Git Bash, there is a menu option Git CMD.

I just tested this on Windows 10, installing Anaconda Python 3.6 64-bit, then Cygwin 64-bit.
My experience:

• python -version reports the correct Anaconda version.
• python appears to hang up and nothing happens, which I guess is starting Python in non-interactive mode.
• ipython hung up on the first attempt, but works fine on further attempts. (After the first attempt I opened Cygwin in the cmd.exe terminal (that is by running C:\cygwin64\Cygwin.bat) where python works. After that ipython worked in the MinTTY terminal. I am not sure if opening Cygwin.bat actually did something to make ipython work in MinTTY, or if it was just coincidence.)
• jupyter notebook works.

[embray]

@evanwill Thanks for the info on that.

On the downside, the cmd.exe console is a terrible user experience (although with the latest Windows 10 service pack it is much better).

I've actually had this problem with other software compiled for Windows that doesn't recognize MinTTY as a pty interface (docker comes to mind). There's a program called winpty that actually fixes this rather nicely. You run your program as winpty python, winpty docker, etc. and it sets up an environment that makes it think it has a pty and act accordingly.

All that said, I think there's still an argument to be made for just using Cygwin's python for the purposes of lessons. Less overhead, much less to install, etc. The only question is whether there are enough packages for it that are needed at least for the basic SWC lessons. Anaconda can also certainly be mentioned as a more complete scientific Python environment, but in terms of KISS I like the idea of using the bare minimum Python to get by (this by no means excludes numpy, scipy, and most other packages--they all work well enough on Cygwin--nor does it exclude using jupyter).

[tracykteal]

It seems like there are enough (many!) good things here to continue to pursue this. If you can put together something for us to try, that would be terrific.

[Denubis]

Hi Tracy. That's absolutely the plan. I'm trying to fit this in among other work commitments, but I'll try to make at least a *little* progress each week. Cheers, -Brian

…

On 8 September 2017 at 05:37, Tracy Teal ***@***.***> wrote: It seems like there are enough (many!) good things here to continue to pursue this. If you can put together something for us to try, that would be terrific. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAO3L9rH5HoqAmFEGC1q4Aa27DDnhjcUks5sgEX_gaJpZM4MYFpw> .

[embray]

@k8hertweck I mean, as I've already said here and elsewhere I've already made a prototype Cygwin installer that would probably be just about ready for field-testing, I think, if even one person tried it out an provided some feedback. I'd be happy to restart work on that if someone tried it out, because it's a solution that I think is easy (almost brainless really) and works well. But otherwise I'm burnt out on the issue.

[embray]

@Denubis

cygwin metapackage and installer. (There is no way I'm getting people to click through the cygwin installer. And, as noted, it's not very nice for drive mapping)

"metapackage" is not necessary--my Cygwin-based installer is built simply by installing Cygwin and the desired packages, then zipping up the resulting filesystem layout and stuffing into a simple InnoSetup installer. The installer unpacks the files on the user's system, installs some shortcuts, and that's it. It's very simple by comparison to any other option I've seen.

I'm not sure what you mean by "drive mapping" but it's possible to use Windows paths in Cygwin like ls C:/ or ls C:\\ (the only disadvantage needing to double backslashes--something that requires explaining).

The only annoyance I have is that files that are hidden in Windows are not hidden from *nix tools which can be rather ugly at times.

[rgaiacs]

I've already made a prototype Cygwin installer that would probably be just about ready for field-testing

Can you provide a link? I will test it to you before go home.

[justbennet]

Eric, I will give it a try on Windows 10 and provide feedback. Do you have a pilot version for Carpentry, or still the Sage installer referred to in the issue?

…

-- bennet

On Thu, Oct 5, 2017 at 10:52 AM, Erik Bray ***@***.***> wrote: @k8hertweck <https://github.com/k8hertweck> I mean, as I've already said here and elsewhere I've already made a prototype Cygwin installer that would probably be just about ready for field-testing, I think, if even one person tried it out an provided some feedback. I'd be happy to restart work on that if someone tried it out, because it's a solution that I think is easy (almost brainless really) and works well. But otherwise I'm burnt out on the issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABhYwgJtMXb65u6rMfkbcQrP7JODwXEoks5spO0vgaJpZM4MYFpw> .

[embray]

@rgaiacs @justbennet Thanks. This comment provides some overview: #11 (comment)
The direct link to the installer is at https://github.com/embray/windows-installer/releases/tag/v0.4a0

It's specifically for SWC, not the Sage one I referred to (but based on it partially). This was before the SWC/DC merge.

At the time I made it the major issues were to do with git/nano/bash/make integration and so its goal was to make something that (hopefully) resolves that area of problems. I wouldn't call it workshop-ready yet because of the as of yet unresolved issue of how to handle Python/R.

For Python some still seem to think installation of Anaconda should be preferred, but in the context of this installer I'm not so sure. Most/all of the Python libraries that might come up in a typical workshop work fine in the standard Python that comes with Cygwin, and in the interest of keeping the installer smaller and better integrated I think that should be preferred, and I don't see much advantage to using Anaconda. That said, I think Anaconda is still worth pointing out as a good scientific Python distribution for Windows, but how that integrates (if at all) with the lesson plan is unclear to me.

[embray]

To be clear I'm not strongly for or against other options, it just seems strange to me that a general consensus would form around options for which nobody is available to provide the experiences and resources to make it work...

[rgaiacs]

if even one person tried it out an provided some feedback

Windows 7 (x86)

• Warning about not signed installer. I'm considering that we could solve this somehow.

• Not support to x86. I wish to have some data to backup my assumption that we don't need to worry too much about it.

Windows 10 (64)

• Same warn about security.

• I just clicked "Next" and it work. Nano didn't clear the terminal which was the latest complain about learners when I was teaching.

Feedback

@embray Thanks for the work. Looks good to me except for the warning.

[embray]

@rgaiacs Thanks for the feedback--
Being that this is just a demo build some things are certain to be the case here:

• No, the installer is not signed. This can be done though for a real release
• I only built a 64-bit version; there's nothing about this that can't be done on 32-bit

Nano didn't clear the terminal which was the latest complain about learners when I was teaching.

Can you clarify this? Are you saying that this is a problem on Cygwin or a problem that this resolved?

[justbennet]

Eric,

I was not able to get to testing yesterday, but I will do so on Sunday. Sorry for the i/o wait. Don't want to drop packets, though.

[rgaiacs]

Being that this is just a demo build some things are certain to be the case here:

• No, the installer is not signed. This can be done though for a real release

+1 I was just creating a record for us not forget. :-)

I only built a 64-bit version; there's nothing about this that can't be done on 32-bit

Great to know.

Nano didn't clear the terminal which was the latest complain about learners when I was teaching.
Can you clarify this? Are you saying that this is a problem on Cygwin or a problem that this resolved?

A problem that this resolved. This problem was what motivated me to write the email that started a previous "text-editor flame war" on the list (that I'm not proud for the record).

[justbennet]

Eric,

I just installed from the web site. Apart from the Windows Defender being disappointed in me for installing anyway, this looks quite great!

All the common programs are in the path and seem to just work: head, tail, nano, man, make, ls, cp, mv, ssh, sftp, vi, sqlite3, rsync, gzip, tar, git, python.

Windows commands are available from the prompt; i.e.,

[cygwin]$ notepad test.txt

opens the file in Notepad.

The one thing that was weird was that the Terminal opened the first time in /etc/skel the first time. Subsequent openings of the Terminal seem to open in the user home directory.

When I am teaching people about bash and scripting, I really want a competent environment that looks like a 'real machine'. This does a very good job of it.

I downloaded via a wireless connection, and it did not take very long. I installed using an account that is an administrator, but I was not prompted for a password or extra authentication.

I installed on Windows 10 Home edition, version 1703.

I think this is much better than the shell that the Git Bash installer left.

This is basically a Cygwin installation, and if the Cygwin setup program were left on the system, then Cygwin would be a useful program, and users/participants would be able to extend or expand their Cygwin environment, if they chose. Perhaps that introduces a complication that shouldn't be introduced in the workshop setting, but a page with supplemental instructions on adding a Cygwin installer would be a cool add-on. Leaving the installer also means that people would be able to update, if they find it useful.

If I recall, unistalling is as simple as removing C:\cygwin and deleting the shortcuts on the desktop and menu, yes?

I don't see anything about this that looks like it might be a hidden gotcha except that initial startup in /etc/skel. Otherwise, I found no surprises.

Thanks for working on this. Sorry I did not get to testing it sooner. I vote for continued development and eventual adoption of this Cygwin installer.

[ChristinaLK]

Just checking in to say thanks to all for building + testing!

Let me know how I can help get this out to the community.

[evanwill]

thanks @embray!
I might include the package chere which adds "Bash Prompt Here" option to the context menu. I find it a very helpful feature and Git Bash has it (so might be good to add for full feature replacement). I find it helps reinforce the connection between the familiar GUI representation of the file system and the terminal--and is a real time saver when people get lost. (the complication is that you need to run chere -i -t mintty in terminal as administrator to install the context menu item, but maybe you can add that to the installer)

Issues are not available on your installer repository, but it might be better to have a more specific conversation over there or in a new thread?

[rgaiacs]

If you are following this issue and didn't read http://opendreamkit.org/2017/10/11/SageWindows/, I right recommend you to do it soon, specially the sections "Rationale for Cygwin and possible alternatives" and "Challenges with 32-bit Windows/Cygwin". @embray works/demo involves Cygwing and I will recommend for us to try to use it in 2018.

[tracykteal]

There's an update that nano will be available in the next Git for Windows release.

The Release Notes for the upcoming release are a work in progress at https://github.com/git-for-windows/build-extra/blob/master/ReleaseNotes.md#changes-since-git-for-windows-v2150-october-30th-2017

Then the release will be available at https://github.com/git-for-windows/git/releases

[justbennet]

Who will decide whether to drop Git for Windows, and when will they do it?

Can I move that an up or down vote be taken by whoever takes such things on the good work @embray did to make an alternative to Git for Windows?

If a vote is anappropriate, then would someone explain who will decide, how, and when? That seems to be a missing and critical component of discussing alternatives.

[ChristinaLK]

@justbennet I've been asked to help shepherd which installer we use, but it's not been entirely clear to me what the process should be, so I'm muddling along slowly. My current feeling is that I'd like to use @embray's work, since it's already ready (as far as I can tell from this thread) and just needs finalizing. I have a call w/ @rgaiacs today and I think we'll discuss and try to determine next steps.

[justbennet]

Christina,

Thanks. I thought it might be helpful to make the decision process more explicit. I hope no one took offense. This just seemed like the situation I've experienced with a lot of co-op arrangements where people are unsure how to move from discussion to decision.

This is also taking place in a side-channel with 15 participants, away from the bulk of instructors, and I do not know whether or how deciding on what to use for the Windows installer would get brought back to the 'committee of the whole', or if it would.

[ChristinaLK]

no offense taken @justbennet. It's helpful to have the push to move forward, so I appreciate it.

[rgaiacs]

I think we'll discuss and try to determine next steps.

I couldn't find plans for the next release. From the release log, looks like they might release something in the next couple of months.

[tracykteal]

Patrick McCann reports that "he noticed a change in the Git Bash installer - apparently since yesterday. When installing 2.15.1, the installer asks if you want to use Nano, Vim (selected by default) or Notepad++ (I've tried attaching a screenshot, but I'm not sure if it will work on the mailing list). After choosing Nano, that program was available to use as soon as installation was complete."

So, this new release seems like it's out. Let's continue to update this issue to see how the new release works in a workshop.

[pgmccann]

Thanks @tracykteal - see also carpentries/workshop-template#447

[ostueker]

Since last week nano is included in the Git-for-Windows installer. (Make sure to use v2.15.1(2) or greater, as the initial v2.15.1 caused some nasty error messages when using vim.)

We have used a combination of Git-for-Windows 2.15.1 and Anaconda3 5.0.1 during a workshop this weekend and I believe most Windows users were unable to start juyter notebook from the "Git Bash".
(Error message was "command not found" i.e. it was not in the PATH)

As we were caught a bit off-guard we used the workaround of starting the Jupyter Notebook via the Start Menu or from the "Anaconda Prompt" which worked until I went to Lesson 10 (Command-Line Programs) in the last 20 min of the workshop.

Three users were not able to install Anaconda3 5.0.1 on Windows. Two of them managed to install the latest Miniconda installer and then install a few extra packages with conda install numpy matplotlib jupyter on the Anaconda Prompt. That didn't work for the third, but he was able to use a Anaconda2 4.4.0 installer.

[evanwill]

I tested Git-for-Windows v2.15.1.2 on Windows 7 and selected the option to use Nano as default editor.

On a fresh install Nano works perfectly as expected. However, when updating from a previous install Nano did not work, resulting in the "redirection not supported" error--so make sure to uninstall the older version first.

Python still does not work directly in the MinTTY terminal--it and other interactive programs need to be started using winpty, i.e. winpty python. Then it works fine. jupyter notebook worked correctly for me.

[ostueker]

(cross-post on carpentries/workshop-template#447 )

I have just confirmed that on a fresh installation on of Git-for-Windows v2.15.1.2 and Anaconda3 v5.0.1, neither the python.exe nor jupyter.exe (or jupyter-notebook.exe) are in the PATH.
Therefore one can't run Python scripts or start the notebook from Git Bash.

This can be addressed in several ways:

• During the installation of Anaconda one can choose to add Anaconda to the PATH.
  However this option is not default and on selecting it results in a red warning show up, basically saying "Don't do that!".
  I don't know what is the rational of that, however I suspect it could cause problems when activating coda environments.
• One could add a line export PATH="${HOME}/Anaconda3:${HOME}/Anaconda3/Scripts:$PATH" to ~/.bashrc. Doing it manually by workshop attendees could be error-prone and require a lot of debugging by helpers.
• It seems that adding source $HOME/Anaconda3/Scripts/activate root to ~/.bashrc also has the desired effect of activating the Anaconda Python.
  This seems to be the cleanest solution but also nothing I would expect all workshop attendees to get right on their first day on the Shell.

Any suggestions?

[ostueker]

I'm continuing the conversation from carpentries/workshop-template#447 to no longer block merging the PR.

Since I wrote the comment above, I'm more and more convinced that in order to activate the Anaconda Python under Git Bash one should use source ~/Anaconda3/Scripts/activate root. This could be added to the ~/.bashrc or ~/.bash_profile.

Questions:

1. On a fresh installation of Git-for-Windows, is there already a ~/.bashrc or ~/.bash_profile present?
   I seem to remember that neither of the files would exist by default but could be created. I currently don't have a Windows machine at hand to test this.
2. Should we add instructions to add the command to ~/.bashrc to the swcarpentry/workshop-template, Python lesson(s) or both?
3. Should we rather update the swcarpentry/windows-installer to exclude nano (as it's now in Git4Win) and rather patch the ~/.bashrc?
4. Should that be done fist thing in the Python lesson by the learners themselves? (This could mean that the instructor has a Windows machine to demo the change.)
5. Other solutions? Write a Shell script to do the change, which has some safe-guards (e.g. check that ~/Anaconda3/Scripts/activate exists).

While I don't really like providing the users with some "magic script that just fixes it", I'm afraid that a significant number of participants would introduce typos when trying to add it themselves. That could cause significant delay at the beginning of the Python session.