swcarpentry / windows-installer

Software Carpentry installer for Windows.
MIT License
21 stars 17 forks source link

Interest in a lightweight Cygwin-based installer? #2

Open ahmadia opened 10 years ago

ahmadia commented 10 years ago

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.

gdevenyi commented 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.

ethanwhite commented 10 years ago

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:

  1. A much higher rate of failed/buggy installs. Back when we used cygwin we were actively discussing abandoning support for Windows entirely and msysgit changed that. Therefore I think it would be important to do at least a few workshops worth of field testing before considering making a switch back to cygwin.
  2. The path issue that @gdevenyi brings up is a serious one. Home in cygwin is not the users home directory (it's an isolated directory off in cygwin land), and getting lost (putting data files and code in different directories, not being able to get back to files after they are created, etc.) is a consistent issue for novices that leaves them behind and frustrated right at the start of the workshop. In addition, constantly being told that "Windows is different" is a negative experience for Windows users.
takluyver commented 10 years ago

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.

ahmadia commented 10 years ago

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.

ethanwhite commented 10 years ago

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.

rgaiacs commented 7 years ago

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.

ethanwhite commented 7 years ago

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.

fmichonneau commented 7 years ago

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

ethanwhite commented 7 years ago

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.

maneesha commented 7 years ago

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.

ethanwhite commented 7 years ago

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.

evanwill commented 7 years ago

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

  1. go to Cygwin and download the setup_x86_64.exe, https://cygwin.com/install.html
  2. move setup_x86_64.exe to a permanent location in your harddrive such as C:\cygwin
  3. open cmd and switch to the directory.
  4. enter the command 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.

evanwill commented 7 years ago

@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).

ethanwhite commented 7 years ago

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

evanwill commented 7 years ago

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

ethanwhite commented 7 years ago

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.

embray commented 7 years ago

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.

embray commented 7 years ago

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.