Open GoogleCodeExporter opened 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
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
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
Heh, looks like we crossed wires :-)
Original comment by s...@seanlip.org
on 3 May 2014 at 5:46
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
shaun...@gmail.com
on 26 Feb 2014 at 5:57