BenHenning / oppia

Automatically exported from code.google.com/p/oppia
Apache License 2.0
0 stars 0 forks source link

test how installation, testing and contributing work on Windows #100

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
The documentation has been written for and testing on Mac and Linux.  It would 
be wonderful to expand for Windows as well.

To contribute to this issue, go to the Developer Documentation 
(https://code.google.com/p/oppia/wiki/DeveloperDocumentation) and go through:
 - https://code.google.com/p/oppia/wiki/Requirements
 - https://code.google.com/p/oppia/wiki/GettingStarted
 - https://code.google.com/p/oppia/wiki/MakingAChange
 - https://code.google.com/p/oppia/wiki/SettingUpTests

If any of the instructions don't make sense to you as a Windows user, cause 
errors, or otherwise seem "off", record that information here in a comment, 
along with information about what version of Windows you're running.

Original issue reported on code.google.com by shaun...@gmail.com on 26 Feb 2014 at 5:57

GoogleCodeExporter commented 9 years ago
I began work on this on a Windows 7 laptop. I installed Git Bash and the first 
issue is that Git Bash does not appear to have apt-get.

Original comment by michaelm...@gmail.com on 3 May 2014 at 5:22

GoogleCodeExporter commented 9 years ago
Never mind previous comment. I realized the intention of apt-get is to install 
wget and setuptools, which I seem to have managed to do by other means. Will 
document all this shortly if I can get it all to work.

Original comment by michaelm...@gmail.com on 3 May 2014 at 5:44

GoogleCodeExporter commented 9 years ago
Ah. Apt-get is the package management tool for Linux, so those instructions (I 
assume you are referring to the introductory ones on the 'Getting Started' 
page) would probably be completely different for Linux, Mac and Windows. It 
would certainly be worth figuring out what the equivalents for Windows are so 
we could include them in the instructions.

I did a bit of searching, and found a few possible alternatives (but I was 
wondering, Asheesh, do you have any advice here?):

For wget:

    http://gnuwin32.sourceforge.net/packages/wget.htm

For python-setuptools:

    https://pypi.python.org/pypi/setuptools#installation-instructions

For git:

    http://msysgit.github.io/

Original comment by s...@seanlip.org on 3 May 2014 at 5:45

GoogleCodeExporter commented 9 years ago
Heh, looks like we crossed wires :-)

Original comment by s...@seanlip.org on 3 May 2014 at 5:46

GoogleCodeExporter commented 9 years ago
For wget, the binaries at this link (the one you listed above) gave errors:

    http://gnuwin32.sourceforge.net/packages/wget.htm

However, this one worked:

    http://eternallybored.org/misc/wget/

This worked for setuptools:

    https://pypi.python.org/pypi/setuptools#windows-7-or-graphical-install

And Git is already part of Git Bash, awesomely. :)

So I cloned the git repository. That's as far as I got because it says the next 
step may take a while and I have to shut down my laptop and drive somewhere. 

Original comment by michaelm...@gmail.com on 3 May 2014 at 6:00

GoogleCodeExporter commented 9 years ago
Next issue, coming after running "bash scripts/start.sh" is that Git-Bash does 
not provide chown, used in line 67 of setup.sh. DOS has 'takeown', and it seems 
that most DOS executables are available in Git-Bash, so you can run 'takeown' 
but unfortunately DOS uses a forward slash for command-line options, which bash 
interprets as directory references and gives errors. I anticipate this will 
prevent most DOS commands from being used in bash scripts. A quick search for 
"chown on Windows" just gives references to people using takeown.

I'll try removing the chown line entirely and see what happens.

Original comment by michaelm...@gmail.com on 3 May 2014 at 6:38

GoogleCodeExporter commented 9 years ago
Yeah -- I theorize you probably don't need the chown stuff on Windows, or
probably on any platform. I haven't read the script, though, so this might
be a misinformed guess.

Original comment by ashe...@asheesh.org on 3 May 2014 at 7:06

GoogleCodeExporter commented 9 years ago
I just removed the chown line and ran start.sh. It got pretty far before 
encountering errors. I was a bit confused by the errors so I ran start.sh 
again. It verified that the Google App Engine was installed, and so was 
webtest. Where it ran into problems was installing node.js. Got "Unsupported 
OS." The script didn't recognize the value of $OS, which in this case was 
'MINGW32_NT-6.1'. At this point I don't know how to proceed. We need to figure 
out which node.js to download. I'm not sure that a test for MINGW32_NT-6.1 
should be hard-coded into install_third_party.sh. Maybe only the first part of 
that is significant.

Original comment by michaelm...@gmail.com on 3 May 2014 at 7:21

GoogleCodeExporter commented 9 years ago
This actually looks really promising, since that is a part of the script that 
checks whether the OS is Mac or Linux. It makes sense to put an additional 
check there for Windows as well, I think; see the second answer in the 
following link:

http://stackoverflow.com/questions/3466166/how-to-check-if-running-in-cygwin-mac
-or-linux

As you say, I think only the first part of that string is significant.

Original comment by s...@seanlip.org on 3 May 2014 at 7:29

GoogleCodeExporter commented 9 years ago
There's one other issue in installing webtest. In start.sh there's a line
  mv $TOOLS_DIR/WebTest-1.4.2 $TOOLS_DIR/webtest-1.4.2

This gives an error in Windows which I suspect is due to case insensitivity. 
The first time I run start.sh it ends at this line with an error (not a very 
helpful error, just says in can't do the move). 

When I run start.sh a second time, when it arrives at this line to test whether 
webtest is installed:

   if [ ! -d "$TOOLS_DIR/webtest-1.4.2" ]; then

This condition is true even though the directory is still called WebTest-1.4.2, 
probably due to Windows case insensitivity. Whether this will cause long-term 
problems, I do not know.

Original comment by michaelm...@gmail.com on 3 May 2014 at 9:42

GoogleCodeExporter commented 9 years ago
I added a test for Windows following the example in that Stack Overflow 
question (a test for MINGW32_NT, specifically) but not sure what to do next 
because I don't know what the node.js link will be. I checked what 
$MACHINE_TYPE was on my machine and it was "i686". 

Original comment by michaelm...@gmail.com on 3 May 2014 at 9:52

GoogleCodeExporter commented 9 years ago
I looked at nodejs.org and noticed the windows installers were in msi format, 
while the Linux and Mac were in gz/tar. I wonder if this is going to affect 
whether the Windows installation can be scripted, as an MSI launches a GUI.

Original comment by michaelm...@gmail.com on 3 May 2014 at 10:52

GoogleCodeExporter commented 9 years ago
Through e.g.
http://stackoverflow.com/questions/181342/automated-msi-installation it is
possible to automatically install an MSI. One thing that is true is that
MSIs typically require administrator privileges to install, and I think
it'd be nice if the Windows setup instructions don't require Administrator.
But having something is surely better than nothing, so go for it, I'd say.

Original comment by ashe...@asheesh.org on 3 May 2014 at 2:53

GoogleCodeExporter commented 9 years ago
Regarding the mv commands which are failing, for instance something like this

    mv WebTest-1.4.2 webtest-1.4.2

gives the error
    mv: cannot move 'WebTest-1.4.2' to 'webtest-1.4.2/WebTest-1.4.2'

I notice it's interpreting this command as moving one directory to a new 
directory. Is that how the mv command works on Linux? I would think from what 
the script seems to be doing that it's supposed to be renaming the directory, 
not moving one under the other.

Original comment by michaelm...@gmail.com on 3 May 2014 at 8:20

GoogleCodeExporter commented 9 years ago
Another approach to #13 is to ask users to explicitly install any necessary 
MSIs, and have the start scripts run on the assumption that these MSIs have 
been installed (so in some places they may simply not do anything). I think 
this would be a perfectly reasonable option.

Regarding #14, it is indeed the case here that mv is supposed to rename the 
directory. Given the case-insensitivity, I wonder if a two-stage rename would 
do the trick (i.e. rename the folder to something completely different, then 
rename it back to webtest-1.4.2 with the correct casing)?

    http://stackoverflow.com/questions/1793735/git-change-case-of-a-file-on-windows

Original comment by s...@seanlip.org on 3 May 2014 at 11:03

GoogleCodeExporter commented 9 years ago
Here's a summary of what I tried:

I installed git-bash from here:
  http://git-scm.com/download/win

I installed wget from here:
  http://eternallybored.org/misc/wget/

I installed setuptools from here:

  https://pypi.python.org/pypi/setuptools#windows-7-or-graphical-install

chown in setup.sh:

  chown doesn't seem to be provided by git-bash. I just removed that line from
  setup.sh 

The next problem happens when start.sh attempts to rename the WebTest-1.4.2
directory to webtest-1.4.2. Due to case insensitivity on windows, mv thinks
these are the same directory and can't execute the request, giving an error. I
notice there are many such mv commands in the scripts for installing things
that get downloaded as .tar.gz files. These would all have to be changed. It
definitely is possible to rename a directory or file to a different case on
Windows, I've done it before.

If I run start.sh again it detects that directory becaue of case
insensitivity, thinks is has already installed webtest, and proceeds past that
point. 

Then in install_third_party.sh it can't find the operating system for
node.js. I tested $OS and its value is "MINGW32_NT-6.1". the node.js is going
to be an msi. it's possible to automate msi installation with msiexec and even
specify a default directory for installation with the TARGETDIR option
according to this source:

https://stackoverflow.com/questions/23449031/get-node-js-for-windows-without-msi

Or, I could try installing the msi manually and copying the relevant files to
the node.0.10.1 directory, but I don't know the structure of that directory or
what files are supposed to go there.

You (Sean) said that I could try running start.sh with the --nojsrepl
option. However this doesn't affect whether it tries to install
node.js. Reading install_third_party.sh, I'm not sure, but it seems to affect
whether it installs CoffeeScript and uglify. It uses npm to install each of
those, and it appears that npm comes with node.js. 

This is where I left off.

Original comment by michaelm...@gmail.com on 4 May 2014 at 10:27

GoogleCodeExporter commented 9 years ago
I got further after removing the portion of the script that installs node.js. I 
got all the way to running GAE and launching the web page!

I'm still interested in installing node.js from the msi download. Can someone 
tell me what files go into oppia_tools/node-0.10.1 (and the directory 
structure) so that I can try to set them up manually?

Original comment by michaelm...@gmail.com on 5 May 2014 at 4:10

GoogleCodeExporter commented 9 years ago
My oppia_tools/node-0.10.1 folder (on Linux Ubuntu 12.04) is 13.6 MB in size, 
and looks like this:

  node-0.10.1
  - bin
    - node
    - npm (symlink)
  - lib
    - dtrace
      - node.d
    - node_modules
      - npm (contains lots of stuff, let me know if you'd like a breakdown)        
  - share
    - man
      - man1
        - node.1
  - ChangeLog
  - LICENSE
  - README.md

Original comment by s...@seanlip.org on 5 May 2014 at 4:23

GoogleCodeExporter commented 9 years ago
Regarding installing node.js on Windows, I'm a bit stymied by the fact the 
Windows installation tree looks so entirely different. I'm starting with trying 
to understand how npm could be run from within Windows, so I'm looking at the 
use of $NPM_INSTALL in install_third_party.sh. Will report back. 

Original comment by michaelm...@gmail.com on 10 May 2014 at 5:53

GoogleCodeExporter commented 9 years ago
Installing the node.js msi creates c:\Program Files (x86)\nodejs with several 
files and a node_modules subdirectory. I'm guessing that this node_modules 
subdir matches the structure of yours.

npm install coffees-script@1.2.0 works without errors, but I'm not clear it's 
doing the right thing. I ran it with cwd=c:\ and it added 
c:\node_modules\coffee-script with a bunch of stuff. I guess I should run it 
with cwd=c:\Program Files (x86)\nodejs. So I did that and it added a 
coffee-script directory to node_modules. Okay, makes sense so far. I'm not sure 
how coffee-script is eventually used.

Original comment by michaelm...@gmail.com on 10 May 2014 at 6:11

GoogleCodeExporter commented 9 years ago
Just updating this thread to reflect the current status -- thanks to Mike, we 
have installation instructions for setting up a development environment for 
Oppia on Windows at this link:

    https://code.google.com/p/oppia/wiki/WindowsGuidelines

with the exception of the code REPL widget. I have also tested installation on 
an old Windows 7 computer and can confirm that it works. Thank you, Michael and 
Asheesh, for all your help with this!

(Leaving this issue open until the code REPL part has been fixed.)

Original comment by s...@seanlip.org on 21 Jul 2014 at 11:29