provide python?

[fmichonneau]

@wking suggested here swcarpentry/workshop-template#173 that the installer could also ship python. That would allow non-python based workshops to run the post-setup scripts (https://github.com/swcarpentry/workshop-template/blob/gh-pages/setup/index.md)

[wking]

On Fri, Mar 13, 2015 at 09:23:14AM -0700, Francois Michonneau wrote:

@wking suggested here swcarpentry/workshop-template#173 that the installer could also ship python. That would allow non-python based workshops to run the post-setup scripts…

Ah, that's not how I had been thinking aout it (although it would also work, I guess). I had been suggesting that the test scripts bundle Python (in the same way that this installer bundles Python 1). However, I'm not sure a terminal flashing briefly past 2 would help much 3, so we'd have to figure that out. If we install Python with the windows-installer, that gets us around the quickly-closed-terminal issue, but we have to worry more about colliding with an existing Python installation. Also, the stuff we currently install is just unpacked into ~/.swc/, but it looks like Python only offers executable installers 4, and I don't know how to drive an installer like that from Python.

[ethanwhite]

Technically there is a Python install that is packaged with the installer, but it's only accessible to the installer itself. If we want people using the Windows Installer to be able to run the test scripts without installing Python I think it would make the most sense to package them together, but I don't know how that would work off the top of my head and don't have the time to investigate it at the moment.

[rgaiacs]

This is creating problems for R based workshops because (1) people get the message that they don't have Python and (2) nano isn't configured.

[apawlik]

@r-gaia-cs I agree. If I understand this discussion, I think it's related to my comment in https://github.com/swcarpentry/workshop-template/issues/136.

[ethanwhite]

This is creating problems for R based workshops because (1) people get the message that they don't have Python

I'm assuming that you mean when the run the checking scripts. If so I think this should be handled in the checking scripts either by having the instructor's comment out the Python check (as is currently recommended) or by improving the reporting to say something like "You have R, but not Python. If this is an R workshop you are good to go."

(2) nano isn't configured.

If nano isn't being configured properly this is a separate issue. The installer should run and install and configure nano, without the need to provide a Python installation that is accessible by the user.

[ethanwhite]

So, if anyone has been experiencing issues with the nano installation please report them in a separate issue.

[ethanwhite]

This is creating problems for R based workshops because (1) people get the message that they don't have Python

Or did you mean when trying to run the test scripts (sorry for my confusion)?

I think there's a bigger question here, which is do we have a reasonable amount of evidence that the check scripts are successfully catching broken installs? If they are, then I think it's worth spending some time making them easier to use, but I'm not currently convinced that adding a Python installation to our Windows installer is the way to go.

What about having the check scripts fall back to the already included Python distribution that runs the installer? Any thoughts on this @wking?

[wking]

On Sun, Jun 07, 2015 at 02:59:06PM -0700, Ethan White wrote:

What about having the check scripts fall back to the already included Python distribution that runs the installer? Any thoughts on this @wking?

There are currently no R checks in the swc-installation-test-2.py script. Mostly because I don't know where the R binaries are on OS X or whether we can assume they're in the PATH their. The SWC Windows installer adds them to the PATH for Windows, and I'd guess Linux users would have them in the PATH by default. I'm also not sure how to figure out their version or the versions of installed packages programatically. If we address all of those issues, then providing the installation-test scripts to Windows users as part of the SWC-installer bundle may make sense (but I can never remember how easy it is for users to view/copy/paste the output of scripts run via Inno Setup).

[embray]

It's only just now dawining on me (although I know I've been told before) that the Windows installer does not actually install Anaconda, R, etc.

Is there are reason we don't do that? I think it would be best.

[wking]

On Mon, Jun 13, 2016 at 10:22:00AM -0700, Erik Bray wrote:

It's only just now dawining on me (although I know I've been told before) that the Windows installer does not actually install Anaconda, R, etc.

Is there are reason we don't do that? I think it would be best.

Because we don't know if a given workshop is going to need Python or R. And because (as far as I know), both packages have GUI installers (which are harder to drive from Python than a tarball we can unpack under ~/.swc).

[embray]

The installer could provide options for R, or Python, or both. Most GUI installers should be driveable headlessly, or unpacked in some way or another. I'll look into what it would take for R--for Anaconda I'm certain it can be done.

Would it be worth it to go ahead and supersede the Python script with a single installer package with everything bundled in it? This is, for example, how the Docker Toolbox for Windows works. It just has everything bundled in it, and the installer itself unpacks and installs everything needed.

[wking]

On Mon, Jun 13, 2016 at 10:37:00AM -0700, Erik Bray wrote:

Would it be worth it to go ahead and supersede the Python script with a single installer package with everything bundled in it?

I don't have access to Windows boxes for testing or much interest in GUI installers. As long as the core installer is a cross-platform Python script, I can help develop it, but I won't be much help if you drop the Python script. That said, there's not all that much going on here, so if you want to strike out on your own with a native GUI installer, it probably wouldn't be that much of an additional maintenance burden.

[embray]

Maybe I could keep the Python script, but for the actual GUI installer, rather than having the installer run the Python script, I would run the python script into a build root that's bundled and extracted by the installer.

[wking]

On Mon, Jun 13, 2016 at 11:07:58AM -0700, Erik Bray wrote:

Maybe I could keep the Python script, but for the actual GUI installer, rather than having the installer run the Python script, I would run the python script into a build root that's bundled and extracted by the installer.

That's not going to work for things like ~/.bash_profile appending 1. And for things like “unpack a tarball” 2 it seems like more trouble than it's worth ;).

[embray]

That's not going to work for things like ~/.bash_profile appending

That seems best left as a post-install step performed by the InnoSetup installer. If you want it could still be done by a Python script called from InnoSetup. I think swc-windows-installer would best be broken into install and post-install steps.

[wking]

On Mon, Jun 13, 2016 at 11:17:57AM -0700, Erik Bray wrote:

That's not going to work for things like ~/.bash_profile appending

That seems best left as a post-install step performed by the InnoSetup installer. If you want it could still be done by a Python script called from InnoSetup. I think swc-windows-installer would best be broken into install and post-install steps.

That might work. And if you like you can leave anything that the Python script can install to the post-install step, only handling the sort of conditional R/Python installs in the “install” step.

[embray]

My one annoyance now is that I want to be able to build the installer without py2exe--I tried to set things up so that the installer can be built in Linux under Wine. But I can't seem to run py2exe in that context. Granted I could try to run Python for Windows in Wine; haven't tried that yet. No idea if it would work.

[wking]

On Mon, Jun 13, 2016 at 11:35:44AM -0700, Erik Bray wrote:

… in Linux under Wine…

Wine is also further than I'm motivated to go ;).

[embray]

@wking What about Docker?

[wking]

On Mon, Jun 13, 2016 at 11:56:32AM -0700, Erik Bray wrote:

@wking What about Docker?

The problem is less about installation (if you're suggesting Wine-in-Docker), than “I don't care enough about Windows to mess with anything outside of my existing toolset” ;). I write Python for a living, so maintaining a Python script that unpacks some tarballs is a very small investment on my part (and I don't have to remind myself how things work six months down the line when someone files the next PR ;).

[embray]

Anyways, sorry, I've carried things off topic. The real point of this issue was mainly about running the post-install checks from the installer (including in R workshops).

I think that should be easy if we combine the post-install tests and swc-windows-installer.py into a single script, perhaps with some sub-commands. Bundle them all into a single script with py2exe.

The first post-install-test would be mostly irrelvant if I bundle Anaconda + R in the installer, with the option for selecting one or the other or both. If Anaconda is installed we can still test the installation, but if only R is installed we can "assume" it's an R workshop and not test for Python (if the user didn't follow instructions and didn't select Python they can uninstall and reinstall or something...)

The second post-install test is trickier since it checks for so many different things, configured per workshop. I think the first step may be to have it consume a simple file or command-line options specifying what it should check for. Need to think more about what do from there...

[wking]

On Mon, Jun 13, 2016 at 12:19:59PM -0700, Erik Bray wrote:

The second post-install test is trickier since it checks for so many different things, configured per workshop. I think the first step may be to have it consume a simple file or command-line options specifying what it should check for. Need to think more about what do from there...

My preferred solution to this is wking/swc-setup-installation-test#9, although folks would still have to either compile a per-workshop installer with their workshop's configurations URL or paste the URL into an installer field. I haven't been able to stir up much support for the installation-test PR though.

[embray]

A question on this--is there a strong reason we need to use Anaconda for Python in the lessons? Is there a lot built around that now?

[gvwilson]

It would take a lot to get us off Anaconda - has proven so much easier than every alternative we've tried for getting a full scientific Python

• Jupyter notebook stack installed on various machines, and for working with them afterward. Best to take it as an immovable object for now.

[embray]

@gvwilson I'm fine with keeping it for now if it has definitely made things easier in that regard. I need to test out how well I can integrate it with Cygwin though. I have started a thread on the topic in the mailing list too.

[gvwilson]

Is the plan to do a Cygwin-based installer and then give people a chance to vote it up or down compared to the Git Bash-based system? We ditched Cygwin for good reasons (mostly to do with the way paths were displayed).

[embray]

I wasn't aware Cygwin was ever tried in the first place. What was the issue with the way paths were displayed?

[gvwilson]

@wking can you fill in some history here?