Two possible approaches for our Windows installer

[ethanwhite]

We currently have a SWC installer for Windows that helps make msysgit/Git Bash/Git for Windows act like the native Bash shells on Linux/Mac. It installs nano, adds it to the path via .bash_profile and handles a couple of other little things. There are three issues with the current version:

1. There is either a Python or Git Bash dependency, which means that if students install things in the wrong order things can fail.
2. Some browsers will open these files as text files instead of downloading them, which confuses the students and sometimes results in extra .txt extensions being added to the file name which stops them from being executed by double clicking.
3. It doesn't look like a Windows installer. It's either a .py file or a .sh file that the student double clicks, something flashes on the screen (so quickly they might not see it), and that's it.

This combination causes errors and confusion for some students. I'm looking into building a proper Windows installer to address these problems and I need a bit of feedback on the approach. We have two basic options that are relatively easy for me to tackle:

1. Add an installer for our current Python script. Doing this will require the students to run the installer and then go to their start menu and run the script. This will remove the first two issues, but may still be a bit confusing since there are two steps and the second step still won't display much.
2. Have the installer handle everything. This is easier if we redistribute nano instead of downloading it. nano is GPL and I don't know if that causes us any issues. Since the installer is a stand alone piece of software it doesn't seem like it would be a big deal to license it GPL, but I haven't thought a lot about these sorts of issues.

Thoughts?

[twitwi]

On the licensing aspect, it should not be an issue to bundle them together, as the programs are actually independent:

• http://www.zdnet.com/blog/burnette/gplv3-myth2-you-cant-mix-gpl-software-with-other-software/331
• http://www.zdnet.com/blog/burnette/gplv3-myth2-you-cant-mix-gpl-software-with-other-software/331

(I'm not a lawyer though :) )

[gvwilson]

I believe Rémi is correct: bundling nano without changes does not
require us to GPL our installer. I also believe Ethan is correct: if we
do need to GPL our installer, we can simply put it in a separate
GitHub project with a separate license.

[wking]

On Sun, Apr 06, 2014 at 04:35:45PM -0700, Greg Wilson wrote:

I believe Rémi is correct: bundling nano without changes does not
require us to GPL our installer.

That matches my understanding about the installer licencing, but the
GPL preamble says:

You must make sure that they, too, receive or can get the source
code. And you must show them these terms so they know their rights.

So we'd want to make sure we did that somehow.

[ethanwhite]

Thanks for all of the feedback on the GPL side of things. Barring additional feedback to the contrary I'll try to build an installer that does everything just using the installer and sticking with all of the existing structure created by our current installer. We would keep the current Python script (slightly modified) to allow us to make future tweaks easily.

If that sounds good to everyone then could we go ahead and merge the most recent version of #357 into bc so that I can work with the most recent state of things inside the main repo?

[wking]

On Mon, Apr 07, 2014 at 07:04:10AM -0700, Ethan White wrote:

I'll try to build an installer that does everything just using the
installer and sticking with all of the existing structure created by
our current installer. We would keep the current Python script
(slightly modified) to allow us to make future tweaks easily.

Sounds good to me. I don't have any experience with more formal
Windows installers, so I'm not sure how the existing script and new
installer logic will fit together. In any case, it will likely be
more difficult for me to test in my Windows-less enviroment. I'm
happy to transfer maintainership of the setup script over to you and
deprecate my git://tremily.us/swc-setup-windows-installer.git
repository. Funneling new changes through my repository would only
clog the pipeline if I no longer have my fingers in all the updates
;).

If that sounds good to everyone then could we go ahead and merge the
most recent version of #357 into bc so that I can work with the
most recent state of things inside the main repo?

This also sounds good to me ;).

[ethanwhite]

I now have (what appears to be) a working build of a Windows installer that runs the Python version of our installation script without the Python dependency (by bringing all of the Python the script needs along for the ride), and with a standard looking graphical installer. It still uses the existing script so we keep the benefits of all the very nice code that @wking has written, which should also be easier for us as a group to maintain, and added a simple Inno Setup script that packages everything necessary to run the script and by default executes it at the end of the installation.

This should address #228 and all of the issues listed above. Now we just need the current version of the Python installer merged in (#357) so that I can build the installer with all of the current goodies. @wking, if that sounds good to you can you merge in #357 when you get the chance.

Sounds good to me. I don't have any experience with more formal Windows installers, so I'm not sure how the existing script and new installer logic will fit together. In any case, it will likely be more difficult for me to test in my Windows-less enviroment. I'm happy to transfer maintainership of the setup script over to you and deprecate my git://tremily.us/swc-setup-windows-installer.git repository. Funneling new changes through my repository would only clog the pipeline if I no longer have my fingers in all the updates ;).

Given the approach I've taken I think it's still natural for you to continue to maintain this since the script is where the things that will be changing will reside. I would prefer to move the central location into swcarpentry to make things slightly easier. One option would be to separate the installer out into a separate swcarpentry repository. Given all of the moving parts for building the installer I think this makes organizational sense, it would ensure that the history doesn't get trampled, and it would allow us to easily distribute the installer through GitHub's release mechanism. Thoughts?

[wking]

On Tue, Apr 08, 2014 at 05:23:10PM -0700, Ethan White wrote:

@wking, if that sounds good to you can you merge in #357
when you get the chance.

I think it's still blocking on a conflict from #389. My preferred
solution to the issue @joonro raises is different from the version
that landed in bc. I'm happy to resolve this in favor of my version
;), but I'd prefer coming to a more clear consensus there (or at least
having some other folk weigh in). I'm probably going to be busy until
sometime next week though, so if someone else wants to handle the
whole thing that's cool too ;).

Given the approach I've taken I think it's still natural for you to
continue to maintain this since the script is where the things that
will be changing will reside.

Ok. If you want to make a PR against my repo, we could proceed with
this while we hash out #389 (with which the installer changes should
not conflict).

I would prefer to move the central location into swcarpentry to
make things slightly easier.

I'm happy to push anywhere folks want mirrors ;). I can't create
repositories under swcarpentry on my own though.

[wking]

On Tue, Apr 08, 2014 at 10:46:39PM -0700, W. Trevor King wrote:

Tue, Apr 08, 2014 at 05:23:10PM -0700, Ethan White:

@wking, if that sounds good to you can you merge in #357
when you get the chance.

I think it's still blocking on a conflict from #389.

Resolved with the just-pushed 3f64f06 (Merge branch
'bc-namespaced-python' of
git://tremily.us/swc-setup-windows-installer, 2014-04-18).

[ethanwhite]

The new installer is in as of a6b41e9.