Hi, I ran into couple of hiccups when using the install script on Ranger, so I thought I'd share. The first is that "svn export" doesn't work with the version of Subversion on Ranger (1.1.4). At least, I'm using it's a version issue, since the command works on my laptop with version 1.4.6. Here's the error: login3$ svn export http://svn.enzotools.org/yt/trunk/doc/ install_script.sh svn: REPORT request failed on '/yt/!svn/vcc/default' svn: Cannot replace a directory from within I don't think this is very big deal, but it may be worth mentioning on the Wiki that "wget http://svn.enzotools.org/yt/trunk/doc/ install_script.sh" is a work around. Personally, I find this preferable, since I really hope I'm not reinstalling so often that I need to update the script regularly. The second bump in the road was when it went to build zlib, since that was the default. I'm not sure that the tried to download the packages, but the URL http://yt.enzotools.org/dependencies/ zlib-1.2.3.tar.bz2 throws a 404. Setting YT_DIR=/share/home/00336/rwagner/yt-x86_64/src/yt-trunk-svn/ tar: zlib-1.2.3.tar.bz2: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors Installing ZLIB ./install_script.sh: line 121: cd: zlib-1.2.3: No such file or directory Failure. Check /share/home/00336/rwagner/yt-x86_64/yt_install.log. This was fixed by setting INST_ZLIB=0. Again, not a big deal. Other than these items, the install went perfectly, and all of the installed packages seem to be working fine. --Rick
Hi Rick, First off, thanks for the report!
I don't think this is very big deal, but it may be worth mentioning on the Wiki that "wget http://svn.enzotools.org/yt/trunk/doc/install_script.sh" is a work around. Personally, I find this preferable, since I really hope I'm not reinstalling so often that I need to update the script regularly.
I've made a note of this on the wiki. (As a side note, 'svn export' actually strips out all the version control information, so it does not embed any metadata/.svn dirs -- I guess wget is easier, though!)
The second bump in the road was when it went to build zlib, since that was the default. I'm not sure that the tried to download the packages, but the URL http://yt.enzotools.org/dependencies/zlib-1.2.3.tar.bz2 throws a 404.
It should make a note of it when it tries to download, although I tell wget to suppress the progress bar. Also, zlib is not among the libraries that are mirrored -- only numpy, matplotlib, ipython and pytables, which are the packages that used to be installed via easy_install, in recent versions of the install_script. Do you think I should mirror zlib? I have absolutely no objection to this; I think this is the first time I've heard of connectivity problems, but if we get any more reports I'll snag it and put it up on yt.e.o. Did it by any chance hang for a *really* long time while it claimed to be downloading? Maybe the connection to the remote server timed out...
This was fixed by setting INST_ZLIB=0. Again, not a big deal.
You can also force it to re-download by removing whatever vestigial traces of zlib-*.gz it has downloaded. The longer term, better solution here is to verify against md5sums; I have not implemented this, but it is (clearly) the right way to do it. It's probably easier to do this with a framework like zc.buildout, but that is not quite as flexible as raw shell scripting for the specific requirements we have -- it's designed much more for egg-based installations, which we're moving away from with yt. ( http://yt.enzotools.org/ticket/175 ) I'll take a look, though, because I've been bitten by weird wget-truncation problems before, too.
Other than these items, the install went perfectly, and all of the installed packages seem to be working fine.
Oh, great! I'm very glad to hear this. Thanks for your report & suggestions! -Matt
Hi Matt,
Did it by any chance hang for a *really* long time while it claimed to be downloading? Maybe the connection to the remote server timed out...
Hmmm...actually, it took forever downloading HDF5 (probably because it was using FTP). I didn't see any errors related to the download, either on the command line, or in the install log.
This was fixed by setting INST_ZLIB=0. Again, not a big deal.
You can also force it to re-download by removing whatever vestigial traces of zlib-*.gz it has downloaded.
That's pretty much what I did; I blew away the install directory and started over to test the process.
The longer term, better solution here is to verify against md5sums; I have not implemented this, but it is (clearly) the right way to do it. It's probably easier to do this with a framework like zc.buildout, but that is not quite as flexible as raw shell scripting for the specific requirements we have -- it's designed much more for egg-based installations, which we're moving away from with yt. ( http://yt.enzotools.org/ticket/175 ) I'll take a look, though, because I've been bitten by weird wget-truncation problems before, too.
I think using a deployment tool like zc.buildout would be good, if you were deploying a variety of tools, instead of just one. As it is, your script builds everything, including Python, on unknown machines, almost flawlessly. It's much more manageable on the platforms we're working on, and better than adding another layer of abstraction. Beside, you'd have to script the Python install, getting bootstrap.py, getting the config file, etc. So, stick with what's working, and hopefully it will help keep the dependencies at a reasonable level, which makes all of our lives easier. --Rick
Hmmm...actually, it took forever downloading HDF5 (probably because it was using FTP). I didn't see any errors related to the download, either on the command line, or in the install log.
A couple weeks ago I had the same problem with HDF5... I've mirrored all the files on the yt.e.o website, and they now verify against MD5 sums.
So, stick with what's working, and hopefully it will help keep the dependencies at a reasonable level, which makes all of our lives easier.
This was basically my thought process, too. :) I evaluated zc.buildout, and had it mostly working, about a year ago -- but it was unwieldy and just not well suited. I guess the shell script is the way to go for now! Thanks again for your input; I hope the new revisions help to provide a more stable installation! -Matt
participants (2)
-
Matthew Turk
-
Rick Wagner