search

carpentries / conversations

Conversations of the Carpentries community
10 stars 2 forks source link

Best strategies for Windows installation #11

Open tracykteal opened 7 years ago

tracykteal commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@k8hertweck Thanks for your investigation. I have a proof of concept in place at https://github.com/swcarpentry/workshop-template/pull/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 commented 7 years ago

@justbennet I think these comments would be most useful directly on the PR @rgaiacs made https://github.com/swcarpentry/workshop-template/pull/391

justbennet commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

Here's a preview for a possible alternative to swcarpentry/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

Downsides

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

TODO

embray commented 7 years ago

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 commented 7 years ago

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:

embray commented 7 years ago

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

beroe commented 7 years ago

Is it worth adding Windows "native" shell support to the list of options? Seems preferable to have an Ubuntu-like experience with apt-get, etc, and Windows 10 should be getting more and more common?

rgaiacs commented 7 years ago

Is it worth adding Windows "native" shell support to the list of options?

We need numbers about how many of our learners are using Windows 10 and how many aren't. Also, we need to know what level of access you need to enable the "native" shell.

dpshelio commented 7 years ago

I'm testing the SWC installer for a workshop we are running this week, from past experiences I've found that some students (I've not managed to find a common denominator between them all) after installing the SWC package didn't get nano. They were getting some files in the installed directory but not nano. The workaround was to install atom (or use notepad++ if the student had already installed it). In that case I've found that if atom is not installed as admin, then it's not added by default in the PATH of the gith bash.

Today I've run the whole installation process on a clear windows 7 vm and found the same behaviour of the swc installer, neither nano nor sqlite were available. However, I've found that there's a SWC channel in conda with nano and there's also sqlite available through the main anaconda channel.

So I've changed the workshop instructions to include: 

conda install -c swc nano=2.4.2

and 

conda install sqlite

that provide with what we need for this workshop. Also, it seems that sqlite in windows works with the readline support which still doesn't on linux/mac (ContinuumIO/anaconda-issues#307).

evanwill commented 7 years ago

@dpshelio did you see swcarpentry/workshop-template/issues/395 ? There is another workshop installing everything via Conda, rather than use the old installer.

naupaka commented 7 years ago

Cmder looks like an interesting option: Site GitHub

Especially this bit (from the README, boldface added by me):

Installation

  1. Download the latest release
  2. Extract the archive
  3. (optional) Place your own executable files into the bin folder to be injected into your PATH
  4. Run Cmder.exe

I tried this with nano.exe and it worked great. It also was simple and straightforward to add sqlite3. git works out of the box. I was not able to get make installed and working, however, because I couldn't find a single-file binary of make for Windows.

We could have a fork of their zip with nano and sqlite3 in the bin/ directory, and from the user's perspective, it would just work.

See also here: https://github.com/cmderdev/cmder/issues/1354

evanwill commented 7 years ago

@naupaka I tested Cmder on Windows 7, the "Full" install. I added nano from the win32-support and Make from ezwinports.

It works pretty well, and solves issues with nano and python present in the default Git Bash / MinTTY. And solves the home directory problem present in Cygwin. However, there are some issues:

twitwi commented 7 years ago

Out of curiosity, I had a quick try with Cmder in a windows (7) VM.

naupaka commented 7 years ago

@twitwi I agree it seems quite promising. I do worry about the reliance on pre-built Windows binaries for the apps we need, though...

embray commented 7 years ago

Did anyone ever test out my idea for a Cygwin-based windows installer here? I never got much feedback on that. I still think that's a very easy approach to this with a lot of advantages, but I'm also sort of burned out on the subject which is why I've been quiet for a while.

k8hertweck commented 7 years ago

Thanks for your patience and for following up on this, @embray. The general consensus was to create an installer using the Git for Windows SDK, which would closely resemble our current installer (which seemed to be the community preference). After a few false starts, however, we've found ourselves struggling to find someone to actually implement this solution. If you would be interested in committing some time to developing a Cygwin solution, I'd be happy to announce its availability for instructors to field test in workshops.

Denubis commented 7 years ago

@k8hertweck Looking around today I happened upon https://chocolatey.org/. Have you folks investigated it (and/or is it worth me investigating?)

I'm also writing up bash oneliners to quickly reference notepad++ and subl. like alias subl='find / -name 'subl' 2> /dev/null | head -n1' into bash_profile

Chocolately was the recommended fix in nano-win, which is why I'm investigating. And a good package manager (in the abstract, at least) would likely be better. I suspect that all of the packages we use could be dropped in with the correct package manager, too.

Having recently deployed cygwin for a colleague, I can probably do something with it if you folks want?

k8hertweck commented 7 years ago

Chocolately looks interesting. I don't have a good sense right now about what particular advantages/disadvantages this might offer for workshops, especially for our learners (e.g., ease of install).

I can say with some confidence the community would be ok with a Cygwin installer, so if you have some time to put a test together that would be great.

The practicality of the Windows installer is that we need a fairly lightweight installer that will be easy for folks to use, but it's becoming clear that we also need a solution that can be community maintained (with enough documentation that you don't need to be an expert in that installer to tweak it later!). Thanks for helping explore some of these options; let me know what you decide to pursue.

Denubis commented 7 years ago

I'm going to have a conversation with them next week.

Advantages: a package manager is a good framework for future interactions, and being able to give the equivalent (in a single dropper) of apt install nano, git, bash, r, R-Studio

Disadvantages: new software with a relatively untested (non OSS) company.

The other route I'll investigate is making a virtual cygwin package https://cygwin.com/packages.html for a one-file installer.

User stories:

As Marcus Aurelius, a learner, I want to run an installer and have the programs show up because I don't have any patience to deal with complicated install steps.

As K'inich Janaab' Pakal, an instructor, I want to have a consistent environment across all of my learners' machines to allow them to see the same output when they run commands because it reduces cognitive load.

Do these fit our full set of intentions? Any other stories we want to add at this point?

twitwi commented 7 years ago

(I cannot reach http://third-bit.com/teaching (ping @gvwilson, if it's not only me).)

I think Alice and Bob should be avoided in general (and especially with these roles) as it may trigger various negative stereotypes.

I think it was discussed there http://third-bit.com/teaching/lessons.html (I cannot get it), that was mentioning:

Review notes to make sure they are free from gendered prouns, that they include culturally diverse names, etc.

It is also in the current version: https://swcarpentry.github.io/instructor-training/16-motivation/ in “Inclusivity” and with a link to Lee's paper:

Be careful not to remind learners of negative stereotypes when teaching.

Denubis commented 7 years ago

@twitwi No worries, happy to use any list of names. I just find it easier to name personae and default to the cryptographic name. These are Certainly not for public release, just as a way of creating user stories. I generally alternate gender every letter and my instructor training personae were quite diverse. But I'll edit them to swap roles.

tracykteal commented 7 years ago

Thanks @Denubis. Having the user stories is a great idea. We could also add for the instructor:

As an instructor, I would like the installer to work across all operating systems and versions, so I don't have to troubleshoot installation with learners.

And we could add a maintainer persona.

As a maintainer, I would like to be able to keep the installer up-to-date with new versions of operating systems or software.

k8hertweck commented 7 years ago

Thanks everyone for helping flesh out our community's needs in selecting an installer.

I'd be interested to hear what @tracykteal, @rgaiacs, and others think about the possible use of non-OSS for an installer?

rgaiacs commented 7 years ago

@k8hertweck I will suggest avoid non-OSS as maximum as possible.

@Denubis Thanks for the comments. If you didn't read https://software-carpentry.org/blog/2017/05/windows-installer.html I would recommend. It is a little out of date. :-(

I think that someone mentioned chocolately on our meeting and we discarded it because, in order of importance, (1) we want something closer to what learners would do by themselves after googling, (2) we want something that is transparent as possible for learners and instructors (this is important to help instructors and helpers troubleshoot the day before the workshop or during it) and (3) work out of the box integrated with other softwares without any note about installation or configuration.

Is very hard to have 1-3 so we need to gave up a little. My order of preference would be

  1. Custom Git Bash installation bundled with nano and other software.

    Note: Git Bash uses MinGW and MSYS under the hood.

  2. conda installation, because conda support both Python and R, the majority of our workshops, and until someone shows me that we teach a reasonable number, at least 25% of last year workshops, of MATLAB workshops I will just say for MATLAB learners to install conda to have bash and nano.

  3. Cygwin

    Note: I don't understand the technical difference between msys, msys2, and cygwin. You can try to make sense of https://stackoverflow.com/a/25023611/1802726.

  4. MSYS2

    Note: I don't understand the technical difference between msys, msys2, and cygwin. You can try to make sense of https://stackoverflow.com/a/25023611/1802726.

  5. chocolately
  6. Wait until we don't care about Windows XP, Windows Vista, Windows 7 or Windows 8 and we can expect that learners will have Windows 10 with Debian/Ubuntu/Fedora/any other GNU/Linux distribution shell available out of the box.
evanwill commented 7 years ago

If we are looking at customized Git Bash, it might be easiest to go back to Cmder (discussed earlier in this thread).

The positive of Git Bash is that it seems the easiest to install and get working, and has a sensible translation of the Windows file system (unlike the other alternatives that create a new home directory, and /cygdrive/).

However, the issue with Git Bash is that the Mintty terminal doesn't work correctly with interactive applications (nano, python, ipython. I am not sure this issue could be overcome even using Git for Windows SDK--if we add Nano, we would still need to use a different terminal emulator). The full install of Cmder is packaged with Git Bash, but uses the ConEmu terminal, that works with Nano, Python, and iPython.

Cmder is fully portable, so rather than creating an installer, some one could just get a version set up with the various binaries and configuration (Git Bash as default shell). The participants install Anaconda, then download the Cmder package, unzip, and are ready to go. I used a Cmder set up in this way (outline), and shared as .zip, in a small workshop teaching command line basics and wget. It seemed to work well.

As discussed above, the weak point is relying on pre-built windows binaries. Some one still has to manually update a special SWC package of Cmder. However, this still may be the best option.

As for Win 10's "Windows Subsystem for Linux", I tried using it in a small command line intro mini-workshop, but had many problems--the install is still fairly complicated. So even though it seems like a good idea, I think it is still a ways off being usable in a workshop setting, even if everyone has Windows 10.

Denubis commented 7 years ago

Cool. I will try to implement very quick demos of a bunch of these. (I'm going to try to get access to a windows VM next week, so I can test on clean installs)

Comments:

Raniere: I absolutely support the OSS-centric approach. (All of my stuff is OSS and I use Linux) -- I'm just investigating alternatives because this was suggested as a mitigation strategy on the nano-win issues page.

Tracey: Thanks for the stories, I'll try to make sure that I have a quick aside per sketch-demo discussing implementation per story. My first pass here is to just have "obvious disqualifiers" on the approaches, especially in light of the "setup workarounds" page that has grown quite significantly.

Raniere (again): I'm going to try to do as little customising as possible, as every manual tweak increases maintnence load. That's why I plan to explore package managers (of whatever stripe -- and looking more deeply at windows package managers in an OSS way) more emphatically.

I like point 6. The reason I've dismissed the linux subsystem for windows out of hand is that it also requires anniversary edition of Win10. (As my boss has learned to her displeasure. It doesn't run on her surface 3). So I think it's 100% the direction to look for in 5 years?

Anyways, thanks for the positive comments folks. (I was ... a little bummed out last night)

Once I get to the point where some package-manager solutions present themselves as obviously (if it cannot justify itself on its own merits then it's not sufficiently better to warrant changing) better than the status quo, I'll solicit you folks for deploy requirements to the VMs to match our most common scenarios so we can elaborate more ably.

On 2 September 2017 at 05:10, EvanWill notifications@github.com wrote:

If we are looking at customized Git Bash, it might be easiest to go back to Cmder http://cmder.net/ (discussed earlier in this thread).

The positive of Git Bash is that it seems the easiest to install and get working, and has a sensible translation of the Windows file system (unlike the other alternatives that create a new home directory, and /cygdrive/).

However, the issue with Git Bash is that the Mintty terminal doesn't work correctly with interactive applications (nano, python, ipython. I am not sure this issue could be overcome even using Git for Windows SDK--if we add Nano, we would still need to use a different terminal emulator). The full install of Cmder is packaged with Git Bash, but uses the ConEmu terminal, that works with Nano, Python, and iPython.

Cmder is fully portable, so rather than creating an installer, some one could just get a version set up with the various binaries and configuration (Git Bash as default shell). The participants install Anaconda, then download the Cmder package, unzip, and are ready to go. I used a Cmder set up in this way (outline https://evanwill.github.io/_drafts/notes/cmdr.html), and shared as .zip, in a small workshop teaching command line basics and wget. It seemed to work well.

As discussed above, the weak point is relying on pre-built windows binaries. Some one still has to manually update a special SWC package of Cmder. However, this still may be the best option.

As for Win 10's "Windows Subsystem for Linux", I tried using it in a small command line intro mini-workshop, but had many problems--the install is still fairly complicated. So even though it seems like a good idea, I think it is still a ways off being usable in a workshop setting, even if everyone has Windows 10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/carpentries/conversations/issues/11#issuecomment-326661715, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO3LykSB9tjj6EH_M-ZbIgneX8WdW0oks5seFa_gaJpZM4MYFpw .

rgaiacs commented 7 years ago

@Denubis Thanks again for your contribution.

If you need Windows virtual machines you can download some at https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. Is my place to go when I need to test things in Windows. You don't need to pay for those VM.

I'm just investigating alternatives because this was suggested as a mitigation strategy on the nano-win issues page.

I understand you. I just see the Carpentries requirements different from a university, research group or company. For the Carpentries, the learners need to install the software by themselves so we need to be careful that (1) they can find information online by themselves if need and (2) our instructions are valid in one year in the future, in other words, we don't change the instructions every 6 months or every year. For a university, research group or company, their IT department will normally install the software on the machine so they can use any "exotic" tool because 1-2 not apply.

Denubis commented 7 years ago

Raniere, thank you so much for that link. You saved me 2 hours of meetings and "what are your project requirements and budget?" to answer that very question. Cheers!

On 2 September 2017 at 17:59, Raniere Silva notifications@github.com wrote:

@Denubis https://github.com/denubis Thanks again for your contribution.

If you need Windows virtual machines you can download some at https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. Is my place to go when I need to test things in Windows. You don't need to pay for those VM.

I'm just investigating alternatives because this was suggested as a mitigation strategy on the nano-win issues page.

I understand you. I just see the Carpentries requirements different from a university, research group or company. For the Carpentries, the learners need to install the software by themselves so we need to be careful that (1) they can find information online by themselves if need and (2) our instructions are valid in one year in the future, in other words, we don't change the instructions every 6 months or every year. For a university, research group or company, their IT department will normally install the software on the machine so they can use any "exotic" tool because 1-2 not apply.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/carpentries/conversations/issues/11#issuecomment-326729328, or mute the thread https://github.com/notifications/unsubscribe-auth/AAO3L9BNbwubTGJTDT5TpphBte4uD74Qks5seQr4gaJpZM4MYFpw .

tracykteal commented 7 years ago

Thanks so much @Denubis. Quick demos of a couple of these would be terrific! I think what's been a main barrier is not being able to try out different approaches. It's hard to tell what will work until we can actually give it a test run! Let us know how we can help. Happy to demo or deploy or whatever will be most useful.

Denubis commented 7 years ago

Hi @tracykteal @rgaiacs

Just making some notes as an aide memoir here. (Stuff is still very much in progress -- let me know if I should take in-progress public notes somewhere else). Just had meeting with chocolatey folk (who wrote up a bit of powershell): https://gist.github.com/ferventcoder/2e2dd0b2131dde871443be9d9f60de89 is a powershell thingo which can be launched by a .bat or .exe. Upsides:

Downsides:

But this is a free and community maintained solution. I'll be kicking the installer (to be written) with the https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ vms, to see if its worth polish.

This strikes me as a route better than writing the raw powershell/bat files ourselves because community maintnence of installers is something that we can benefit from.

I was typing that this was disqualified at start, but I've been persuaded to try it. The first scoping task is "What is the easiest route to a metapackage" in all of these things -- insofar as it replicates the manual setup instructions on the setup line and has good similarity to other approaches in other OSes.

Other approaches: