Open ahmadia opened 10 years ago
I highly endorse cygwin as opposed to msysgit, it's much more feature complete and easy to add the extra packages.
Does your installer hide the uglyness that is cygwin's default installer?
My one concern is from what I recall the cygwin file structure is different than what msysgit presents which may cause issues in the lessons.
It would certainly be nice to not run into the gotcha's of missing commands like man
. It is worth noting that nano
is no longer an issue because our installer handles that.
The two problems that we've had historically with cygwin are:
For the Python components, I would be inclined to keep running them on 'real Windows', i.e. not cygwin. At least in IPython, we certainly have better testing and support for running natively on Windows than we do on cygwin, and I think installation of the scipy stack is less of an issue than it used to be.
Whether it's worth using cygwin to get Unixy utilities like the shell and nano, I'm not so sure about.
Does your installer hide the uglyness that is cygwin's default installer?
Yes, it's NSIS-based thanks to @takluyver, but requires that the install is "pre-baked". After installation, it's easy to set up "Applications" that drive IPython notebooks, terminals, and otherwise.
My one concern is from what I recall the cygwin file structure is different than what msysgit presents which may cause issues in the lessons.
The Cygwin directory structure can be remapped to look like the msysgit presentation, with a mount such as:
/cygdrive/c/Documents\040and\040Settings/[user name] /home/[user name] ntfs binary,noacl,bind 0 0
Normally, the home drive is mounted to something like:
/cygdrive/c/cygwin/home/[user name]
It would require some trickery to do this at install time, but it wouldn't be impossible.
I'm not sure this is worth pursuing, but I did want to make it an option if people were interested.
Closing for the moment. If SWC decides to move back in the direction of cygwin then I think this could be a great way to do this, but that should be part of a larger SWC wide discussion.
I'm reopen this issue after the discussion started at the discuss list, see http://lists.software-carpentry.org/pipermail/discuss/2017-March/005085.html for the first email.
I'm no longer maintaining this project - @embray & @wking are the current folks I believe, but I'll go ahead and reopen this. My concerns about using cygwin in the above comment, most notably (2), still stand.
it would only work for windows 10 64-bit, but there is now support for bash on windows: https://msdn.microsoft.com/en-us/commandline/wsl/about
it would only work for windows 10 64-bit, but there is now support for bash on windows: https://msdn.microsoft.com/en-us/commandline/wsl/about
I think this should definitely be plan for Windows 10 and that we should go ahead and develop those instructions for the installation page. Note that it's not all versions of Windows 10, only new updates, so that may cause some confusion, but it I think it's definitely the long-term direction to head.
We can offer this for Windows 10 users. I also think a lot of users are still going be on 7 or 8 so we do need to have a working install we can offer.
I also think a lot of users are still going be on 7 or 8 so we do need to have a working install we can offer.
+100 and this will probably continue to be the case for several years.
The easiest way to get people set up with Cygwin is not to create an installer, but just have them download the standard setup exe
, and give users the command line options to install everything they need.
For example (would have to be tested and explained more carefully):
setup_x86_64.exe
, https://cygwin.com/install.htmlsetup_x86_64.exe
to a permanent location in your harddrive such as C:\cygwincmd
and switch to the directory.setup-x86_64.exe -q -P git,make,sqlite3,wget,ninvaders
After entering the command the installer opens a window with status bars for downloading the package, but it requires no input. It will install Cygwin in the default location, C;\cygwin64
What I like about this option is that it's an existing tool that does what we need, that we don't have to maintain ourselves. It has an existing tool to update and install further packages if necessary.
It is worth mentioning that the version of Nano the current SWC installer adds to Git Bash was compiled using Cygwin (years ago) and ships with the cygwin dll and other utilities to make it work. So in trying to get Nano to work with Git Bash, we are actually installing cygwin in a roundabout way.
@ethanwhite does the SWC installer reset the /
path for Git Bash?
You mention the confusion over the weird fake root directory in Cygwin. However, the current default Git for Windows install also creates a fake root and home directory some where in your application files, something like C:\Program Files\Git\mingw64\
. If you cd /
you end up there.
In a recent intro to Shell workshop I used this difference to explain the Linux file system. I think it's really confusing if not explained to new users, but not a barrier to use since there is differences in the file systems and it will ultimately be just as confusing to have /
or /home/
mounted to a Windows equivalent (since the contents will not match the Linux system at all).
@evanwill The issue isn't actually with the root directory, it's with the home directory. A default Git Bash install uses the users home folder C:\Users\username
. This means that cd Desktop
will take students to a location that all of them are familiar with and this works the same way across all operating systems. In contrast Cygwin creates it's own home directory that doesn't naturally tie in with the basic locations that students are used to thinking about, and it requires that Windows users due something different to get to the common location of the desktop. One of the most common issues that Windows users new to the terminal run into is getting lost in the file system and not understanding where they are and how the terminal relates to the ways they are used to navigating. My experience, and I think it's fair to say our collective experience in experimenting with Cygwin vs Git Bash ~5 years ago was that beginners were less likely to get lost/confused by this when home is in the standard location.
@ethanwhite I was confused by what you were saying (i.e. on Git Bash cd ~
goes to C:\Users\username
) because I had only used it on a Windows 7 enterprise system with centrally managed users, and that isn't true on that computer--but I just tested a new install on Windows 10 and confirmed you are correct on a normal Windows setup.
None-the-less, I am not sure the bit of confusion getting started with the "fake root / home" location of cygwin is the deal breaker. That being said, I haven't used cygwin in a workshop, I have always just used default Git Bash when teaching Shell and Git.
One of the things we done in the past to figure out what stacks are best is to run experiments. Develop the full set of instructions/tools for the stack, run some workshops that way, see how the problems are compared to those experienced with the existing stack. That's what lead to the initial switch from cygwin to Git Bash. I'd certainly encourage ongoing experimentation to find the most stable, simple to setup, easy for students to use during the workshops, and easy to maintain stacks as possible.
Short comment for now since I'm on vacation, but FWIW - - I've been working on a Windows version of SageMath based on Cygwin, for which I've made a well-working (so far, based on feedback I've gotten) InnoSetup based installer.
For the most part it just unpacks a pre-made Cygwin installation with all the desires packages installed. It also sets up a directory under C:\Users\<Username>
that it mounts as the home directory, with ACL-based permission support, plus a few other settings. I've found through personal experience that making C:\Users\<Username>
itself the home directory makes a mess of permission handling. But a directory just under it typically works fine. One can also mount C:\Users\<Username>
separately as a subdirectory of their home directory, but that's a bit confusing maybe. Otherwise it really works well.
The one thing I have not tried is mixing Anaconda with Cygwin, and that's the main reason I haven't made any more progress on this yet. But my plan for a while has been to adapt my SageMath installer for a Cygwin-based package for SWC.
In contrast Cygwin creates it's own home directory that doesn't naturally tie in with the basic locations that students are used to thinking about, and it requires that Windows users due something different to get to the common location of the desktop.
As I alluded to above this can be changed freely by customizing /etc/fstab
or a user-specific /etc/fstab.d/
file. My SageMath installer has an /etc/profile
(IIRC) that automatically creates the latter if it does not already exist, so that a different path is mounted /home/username
when the first log in.
As part of my work for the Corps, I adapted @takluyver's pynsist package and leveraged hashdist to build a lightweight one-click binary installer of the Cygwin operating system to support the usual scipy-stack including the IPython Notebook.
It's an attractive alternative to msysgit in the sense that Cygwin is missing far fewer things (
nano
,man
), but it puts a heavier maintenance burden on the Software Carpentry team. I'm happy to explain the build system if somebody is interested in trying it out for themselves. It's been tested on Windows 8 and Windows 7, but is not very well-documented or publicly hosted yet.