I would be in favor of one tarball for simplicity. Are the example files that large?<div><br></div><div>- Casey</div><div><br><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 10:48 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John,<br>
<br>
Hm, that's puzzling.  Stephen, any ideas?<br>
<br>
After Stephen's email, I went from +0 on keeping the downloader to +1,<br>
because I think having it from the command line is a much simpler<br>
solution than what we had tried before, which was the<br>
download-by-hand.  So let's see if we can address this, and then check<br>
it in to scripts/ .<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jul 24, 2012 at 1:45 PM, John ZuHone <<a href="mailto:jzuhone@gmail.com">jzuhone@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> What I don't like about the downloader is the directory structure it creates. At least on my machine, if I download only the sloshing dataset, I get:<br>
><br>
> GasSloshing/GasSloshing/sloshing_nomag2*<br>
><br>
> as the location of the files. Is there any reason why it ended up this way?<br>
><br>
> John<br>
><br>
> On Jul 24, 2012, at 11:26 AM, Stephen Skory wrote:<br>
><br>
>> Hi Matt,<br>
>><br>
>>> One question that's come up is: do we want to continue using<br>
>>> download.py?  The burden on uploaders is moderately higher, in that<br>
>>> the files all have to be tarred up in a particular way, and they have<br>
>>> to be added to download.py, but it does provide a measure of<br>
>>> robustness.  If we do this, can we move download.py into the main<br>
>>> distribution, under scripts/ ?  Stephen, John, others who have used<br>
>>> the script, what do you think about this?<br>
>><br>
>> I will not be insulted if we do away with the download script. If a<br>
>> web page of download links is easier for everyone around, that's fine<br>
>> by me. The best argument I can think of for keeping it, or something<br>
>> similar, it is forces some kind of uniformity so that the datasets are<br>
>> in an expected layout. Also, downloading tens of data dumps one at at<br>
>> time from a webpage is kind of tedious. That could be solved by having<br>
>> both the separate data dumps and a big 'ol tarball of the whole thing<br>
>> so people could get exactly what they want, but that doubles disk<br>
>> space on someone's computer.<br>
>><br>
>> But this isn't HIPPA medical data, so we can be loosie goosie if that<br>
>> makes things easier for everyone!<br>
>><br>
>> --<br>
>> Stephen Skory<br>
>> <a href="mailto:s@skory.us">s@skory.us</a><br>
>> <a href="http://stephenskory.com/" target="_blank">http://stephenskory.com/</a><br>
>> <a href="tel:510.621.3687" value="+15106213687">510.621.3687</a> (google voice)<br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>