Hi all, After a few days of hard work, Britton, Matt, and I are pleased to announce that a major reorganization of yt is complete. This is the biggest part of what will become yt-2.0, and encompasses nearly all of the codebase. We have pushed it to the tip of the yt branch in the hg repository today. PLEASE NOTE you MUST reclone (not hg pull!) your mercurial repository from hg.enzotools.org! Just move your old repository out of the way and do hg clone http://hg.enzotools.org/yt Finally, please note that as of today SVN is read only. You can still use the SVN repository for now, but it will no longer acquire any new changes. We have done a good amount of testing, but there are sure to be places where things break. Please report anything you find to the issue tracker (http://yt.enzotools.org/newticket) as soon as you can. The changes have almost all been organizational, except for the addition of a new QuadTree method for projections, which Matt pushed to the yt branch ahead of this. Furthermore, unless you do something **other** than from yt.mods import * *everything* should be exactly the same for all of your scripts. We would really appreciate it if you could file a ticket (http://yt.enzotools.org/newticket) if you find anything that imports only from yt.mods doesn't work. The biggest change is that the old module Snow Crash-derived module names (lagos, raven, fido, enki) have been removed, and the code has been divided up into new set of modules, with descriptive names: drwxr-xr-x 21 joishi joishi 714 Aug 27 11:49 analysis_modules drwxr-xr-x 31 joishi joishi 1.0k Aug 28 08:45 data_objects drwxr-xr-x 15 joishi joishi 510 Aug 26 16:57 frontends drwxr-xr-x 9 joishi joishi 306 Aug 28 08:45 gui drwxr-xr-x 46 joishi joishi 1.5k Aug 28 08:45 utilities drwxr-xr-x 38 joishi joishi 1.3k Aug 28 16:09 visualization The second biggest change, and perhaps the more important one (especially to yt developers) is the redesign of how we access component pieces within and outside of yt. Previously, within yt, importing modules from one part of the code to another was accomplished by things like from lagos import * in the __init__.py file of another module. This has two negative effects: first, it pollutes the namespaces with many unnecessary classes and functions (greatly raising the possibility of a collision), and second, it creates circular imports which can slow down import times for yt. In order to solve these two problems, we emptied out __init__.py of everything except a docstring in every module and replaced them with api.py files. Each module has a api.py file containing a list of imports of each class or function wihthin that module imported individually to the API. For example, here is the visualization api.py: from color_maps import \ add_cmap from plot_collection import \ PlotCollection, \ PlotCollectionInteractive, \ concatenate_pdfs, \ get_multi_plot from fixed_resolution import \ FixedResolutionBuffer, \ ObliqueFixedResolutionBuffer from image_writer import \ multi_image_composite, \ write_bitmap, \ write_image, \ map_to_colors, \ splat_points from plot_modifications import \ PlotCallback, \ callback_registry In order to use a function from the yt/visualization package, you would add the following import lines to your script: from yt.mods import * # this hasn't changed from yt.visualization.api import PlotCollection pf = load("AwesomeTown0132") pc = PlotCollection(pf) The third major change was to move extensions to analysis_modules. This will likely affect many people in a purely cosmetic way; for example, the halo finder is now imported by adding the following line to your script: from yt.analysis_modules.halo_finding.api import HaloFinder a bit wordier, but much cleaner. If you are developing yt, please note that the api.py file is for EXTERNAL scripts only. Anything INTERNAL to yt must directly import any class or function necessary by directly referencing the file it resides in, e.g.: from .fixed_resolution import FixedResolutionBuffer. Finally, Volume Rendering has been relocated to the new visualization module. It should otherwise be unchanged (except the api.py change, of course). Full notes on all these changes can be found on the wiki: http://yt.enzotools.org/wiki/yt-2.0 We hope this will lead to a much cleaner, more hackable, more understandable yt. yt-2.0 will also include a new, simpler plotting interface. Please feel free to contact Britton, Matt, or me if you have any questions or any problems with the new yt. Thanks! Jeff Matt Britton