[yt-svn] commit/yt: 13 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Thu May 26 06:14:50 PDT 2016
13 new commits in yt:
https://bitbucket.org/yt_analysis/yt/commits/7d1530e7c480/
Changeset: 7d1530e7c480
Branch: yt
User: jzuhone
Date: 2015-05-26 16:17:23+00:00
Summary: First stab at Appveyor testing
Affected #: 2 files
diff -r c12349973350b9c9b2f4c60af9a7bc6b90ea42e2 -r 7d1530e7c480130c3e6978e60193d9c4b8ccb2f5 appveyor.yml
--- /dev/null
+++ b/appveyor.yml
@@ -0,0 +1,54 @@
+# AppVeyor.com is a Continuous Integration service to build and run tests under
+# Windows
+
+environment:
+
+ global:
+ PYTHON: "C:\\conda"
+ MINICONDA_VERSION: "3.5.5"
+ CMD_IN_ENV: "cmd /E:ON /V:ON /C .\\.continuous-integration\\appveyor\\windows_sdk.cmd"
+ PYTHON_ARCH: "64" # needs to be set for CMD_IN_ENV to succeed. If a mix
+ # of 32 bit and 64 bit builds are needed, move this
+ # to the matrix section.
+
+ matrix:
+
+ # We test Python 2.6 and 3.4 because 2.6 is most likely to have issues in
+ # Python 2 (if 2.6 passes, 2.7 virtually always passes) and Python 3.4 is
+ # the latest Python 3 release.
+
+ - PYTHON_VERSION: "2.7"
+ NUMPY_VERSION: "1.9.1"
+
+ #- PYTHON_VERSION: "3.4"
+ # NUMPY_VERSION: "1.9.1"
+
+platform:
+ -x64
+
+install:
+ # Install miniconda using a powershell script.
+ - "powershell doc/install-miniconda.ps1"
+ - "SET PATH=%PYTHON%;%PYTHON%\\Scripts;%PATH%"
+
+ # Install the build and runtime dependencies of the project.
+ - "conda update --yes conda"
+ # Create a conda environment using the astropy bonus packages
+ - "conda create -q --yes -n test -c yt-ci python=%PYTHON_VERSION%"
+ - "activate test"
+
+ # Check that we have the expected version of Python
+ - "python --version"
+
+ # Install specified version of numpy and dependencies
+ - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools mingw Cython sympy h5py matplotlib"
+ - "hg clone http://bitbucket.org/jzuhone/yt-windows"
+ - "hg update -C yt-windows"
+ - "cd yt-windows"
+
+# Not a .NET project, we build SunPy in the install step instead
+build: false
+
+test_script:
+ - "nosetests ."
+
diff -r c12349973350b9c9b2f4c60af9a7bc6b90ea42e2 -r 7d1530e7c480130c3e6978e60193d9c4b8ccb2f5 doc/install-miniconda.ps1
--- /dev/null
+++ b/doc/install-miniconda.ps1
@@ -0,0 +1,71 @@
+# Sample script to install anaconda under windows
+# Authors: Stuart Mumford
+# Borrwed from: Olivier Grisel and Kyle Kastner
+# License: BSD 3 clause
+
+$MINICONDA_URL = "http://repo.continuum.io/miniconda/"
+
+function DownloadMiniconda ($version, $platform_suffix) {
+ $webclient = New-Object System.Net.WebClient
+ $filename = "Miniconda-" + $version + "-Windows-" + $platform_suffix + ".exe"
+
+ $url = $MINICONDA_URL + $filename
+
+ $basedir = $pwd.Path + "\"
+ $filepath = $basedir + $filename
+ if (Test-Path $filename) {
+ Write-Host "Reusing" $filepath
+ return $filepath
+ }
+
+ # Download and retry up to 3 times in case of network transient errors.
+ Write-Host "Downloading" $filename "from" $url
+ $retry_attempts = 2
+ for($i=0; $i -lt $retry_attempts; $i++){
+ try {
+ $webclient.DownloadFile($url, $filepath)
+ break
+ }
+ Catch [Exception]{
+ Start-Sleep 1
+ }
+ }
+ if (Test-Path $filepath) {
+ Write-Host "File saved at" $filepath
+ } else {
+ # Retry once to get the error message if any at the last try
+ $webclient.DownloadFile($url, $filepath)
+ }
+ return $filepath
+}
+
+function InstallMiniconda ($python_version, $architecture, $python_home) {
+ Write-Host "Installing miniconda" $python_version "for" $architecture "bit architecture to" $python_home
+ if (Test-Path $python_home) {
+ Write-Host $python_home "already exists, skipping."
+ return $false
+ }
+ if ($architecture -eq "x86") {
+ $platform_suffix = "x86"
+ } else {
+ $platform_suffix = "x86_64"
+ }
+ $filepath = DownloadMiniconda $python_version $platform_suffix
+ Write-Host "Installing" $filepath "to" $python_home
+ $args = "/InstallationType=AllUsers /S /AddToPath=1 /RegisterPython=1 /D=" + $python_home
+ Write-Host $filepath $args
+ Start-Process -FilePath $filepath -ArgumentList $args -Wait -Passthru
+ #Start-Sleep -s 15
+ if (Test-Path C:\conda) {
+ Write-Host "Miniconda $python_version ($architecture) installation complete"
+ } else {
+ Write-Host "Failed to install Python in $python_home"
+ Exit 1
+ }
+}
+
+function main () {
+ InstallMiniconda $env:MINICONDA_VERSION $env:PLATFORM $env:PYTHON
+}
+
+main
https://bitbucket.org/yt_analysis/yt/commits/64acd1d3885c/
Changeset: 64acd1d3885c
Branch: yt
User: jzuhone
Date: 2015-05-26 16:20:27+00:00
Summary: line spacing issues?
Affected #: 1 file
diff -r 7d1530e7c480130c3e6978e60193d9c4b8ccb2f5 -r 64acd1d3885cc03c89a6f70999048603d99a74c3 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -42,9 +42,9 @@
# Install specified version of numpy and dependencies
- "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools mingw Cython sympy h5py matplotlib"
- - "hg clone http://bitbucket.org/jzuhone/yt-windows"
- - "hg update -C yt-windows"
- - "cd yt-windows"
+ - "hg clone http://bitbucket.org/jzuhone/yt-windows"
+ - "hg update -C yt-windows"
+ - "cd yt-windows"
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/a8061ebcd070/
Changeset: a8061ebcd070
Branch: yt
User: jzuhone
Date: 2015-05-26 16:21:17+00:00
Summary: More line spacing issues
Affected #: 1 file
diff -r 64acd1d3885cc03c89a6f70999048603d99a74c3 -r a8061ebcd070e0fcd34d76a79457c62f7724ab39 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -45,7 +45,7 @@
- "hg clone http://bitbucket.org/jzuhone/yt-windows"
- "hg update -C yt-windows"
- "cd yt-windows"
-
+
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/b2888d126134/
Changeset: b2888d126134
Branch: yt
User: jzuhone
Date: 2015-05-26 16:41:41+00:00
Summary: More line spacing
Affected #: 1 file
diff -r a8061ebcd070e0fcd34d76a79457c62f7724ab39 -r b2888d12613422f32ae3d1121381850bd361d7e1 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -45,7 +45,7 @@
- "hg clone http://bitbucket.org/jzuhone/yt-windows"
- "hg update -C yt-windows"
- "cd yt-windows"
-
+
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/24fa54bd9c9c/
Changeset: 24fa54bd9c9c
Branch: yt
User: jzuhone
Date: 2015-05-26 16:52:20+00:00
Summary: I obviously didn't know what I was doing when I did this.
Affected #: 1 file
diff -r b2888d12613422f32ae3d1121381850bd361d7e1 -r 24fa54bd9c9c05372ab86d75825035cabdf436dd appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -34,7 +34,7 @@
# Install the build and runtime dependencies of the project.
- "conda update --yes conda"
# Create a conda environment using the astropy bonus packages
- - "conda create -q --yes -n test -c yt-ci python=%PYTHON_VERSION%"
+ - "conda create -q --yes -n test python=%PYTHON_VERSION%"
- "activate test"
# Check that we have the expected version of Python
https://bitbucket.org/yt_analysis/yt/commits/ecc11b8f4f47/
Changeset: ecc11b8f4f47
Branch: yt
User: jzuhone
Date: 2015-05-26 18:42:34+00:00
Summary: Getting these commands right
Affected #: 1 file
diff -r 24fa54bd9c9c05372ab86d75825035cabdf436dd -r ecc11b8f4f4788b8acf683df0676b3aa2d651147 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -43,9 +43,10 @@
# Install specified version of numpy and dependencies
- "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools mingw Cython sympy h5py matplotlib"
- "hg clone http://bitbucket.org/jzuhone/yt-windows"
- - "hg update -C yt-windows"
- "cd yt-windows"
-
+ - "hg update -C yt"
+ - "python setup.py build --compiler=mingw32 install"
+
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/89961c5586a3/
Changeset: 89961c5586a3
Branch: yt
User: jzuhone
Date: 2015-05-26 18:44:06+00:00
Summary: Line spacing!
Affected #: 1 file
diff -r ecc11b8f4f4788b8acf683df0676b3aa2d651147 -r 89961c5586a30f7d773efc3be2d627b77193a8bc appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -46,7 +46,7 @@
- "cd yt-windows"
- "hg update -C yt"
- "python setup.py build --compiler=mingw32 install"
-
+
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/3cb7d3ce5db7/
Changeset: 3cb7d3ce5db7
Branch: yt
User: jzuhone
Date: 2015-05-26 18:54:04+00:00
Summary: Fix line spacing
Affected #: 1 file
diff -r 89961c5586a30f7d773efc3be2d627b77193a8bc -r 3cb7d3ce5db736a017db7920f14e1271dc6f1098 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -33,7 +33,7 @@
# Install the build and runtime dependencies of the project.
- "conda update --yes conda"
- # Create a conda environment using the astropy bonus packages
+ # Create a conda environment
- "conda create -q --yes -n test python=%PYTHON_VERSION%"
- "activate test"
@@ -46,7 +46,7 @@
- "cd yt-windows"
- "hg update -C yt"
- "python setup.py build --compiler=mingw32 install"
-
+
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/6fb631e95238/
Changeset: 6fb631e95238
Branch: yt
User: jzuhone
Date: 2015-05-26 19:14:16+00:00
Summary: Fixing more bugs
Affected #: 1 file
diff -r 3cb7d3ce5db736a017db7920f14e1271dc6f1098 -r 6fb631e9523814b594d141a13004af38f06edea4 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -41,10 +41,7 @@
- "python --version"
# Install specified version of numpy and dependencies
- - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools mingw Cython sympy h5py matplotlib"
- - "hg clone http://bitbucket.org/jzuhone/yt-windows"
- - "cd yt-windows"
- - "hg update -C yt"
+ - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools libpython mingw Cython sympy h5py matplotlib"
- "python setup.py build --compiler=mingw32 install"
# Not a .NET project, we build SunPy in the install step instead
https://bitbucket.org/yt_analysis/yt/commits/8ec2c74b6154/
Changeset: 8ec2c74b6154
Branch: yt
User: jzuhone
Date: 2015-05-26 19:51:41+00:00
Summary: Removing cruft--do develop in here
Affected #: 1 file
diff -r 6fb631e9523814b594d141a13004af38f06edea4 -r 8ec2c74b6154dc3f765012d868acd402e6a4c984 appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -6,17 +6,9 @@
global:
PYTHON: "C:\\conda"
MINICONDA_VERSION: "3.5.5"
- CMD_IN_ENV: "cmd /E:ON /V:ON /C .\\.continuous-integration\\appveyor\\windows_sdk.cmd"
- PYTHON_ARCH: "64" # needs to be set for CMD_IN_ENV to succeed. If a mix
- # of 32 bit and 64 bit builds are needed, move this
- # to the matrix section.
matrix:
- # We test Python 2.6 and 3.4 because 2.6 is most likely to have issues in
- # Python 2 (if 2.6 passes, 2.7 virtually always passes) and Python 3.4 is
- # the latest Python 3 release.
-
- PYTHON_VERSION: "2.7"
NUMPY_VERSION: "1.9.1"
@@ -43,6 +35,7 @@
# Install specified version of numpy and dependencies
- "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools libpython mingw Cython sympy h5py matplotlib"
- "python setup.py build --compiler=mingw32 install"
+ - "python setup.py develop"
# Not a .NET project, we build SunPy in the install step instead
build: false
https://bitbucket.org/yt_analysis/yt/commits/69e32dee2a2e/
Changeset: 69e32dee2a2e
Branch: yt
User: jzuhone
Date: 2016-05-19 20:03:18+00:00
Summary: We build with MSVC now
Affected #: 1 file
diff -r 8ec2c74b6154dc3f765012d868acd402e6a4c984 -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -12,9 +12,6 @@
- PYTHON_VERSION: "2.7"
NUMPY_VERSION: "1.9.1"
- #- PYTHON_VERSION: "3.4"
- # NUMPY_VERSION: "1.9.1"
-
platform:
-x64
@@ -33,8 +30,7 @@
- "python --version"
# Install specified version of numpy and dependencies
- - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools libpython mingw Cython sympy h5py matplotlib"
- - "python setup.py build --compiler=mingw32 install"
+ - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools Cython sympy h5py matplotlib"
- "python setup.py develop"
# Not a .NET project, we build SunPy in the install step instead
https://bitbucket.org/yt_analysis/yt/commits/91e941b6a3d4/
Changeset: 91e941b6a3d4
Branch: yt
User: jzuhone
Date: 2016-05-19 20:04:02+00:00
Summary: Merge
Affected #: 987 files
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 .hgchurn
--- a/.hgchurn
+++ b/.hgchurn
@@ -1,6 +1,6 @@
stephenskory at yahoo.com = s at skory.us
"Stephen Skory stephenskory at yahoo.com" = s at skory.us
-yuan at astro.columbia.edu = bear0980 at gmail.com
+bear0980 at gmail.com = yuan at astro.columbia.edu
juxtaposicion at gmail.com = cemoody at ucsc.edu
chummels at gmail.com = chummels at astro.columbia.edu
jwise at astro.princeton.edu = jwise at physics.gatech.edu
@@ -19,7 +19,31 @@
sername=kayleanelson = kaylea.nelson at yale.edu
kayleanelson = kaylea.nelson at yale.edu
jcforbes at ucsc.edu = jforbes at ucolick.org
-ngoldbau at ucsc.edu = goldbaum at ucolick.org
biondo at wisc.edu = Biondo at wisc.edu
samgeen at googlemail.com = samgeen at gmail.com
-fbogert = fbogert at ucsc.edu
\ No newline at end of file
+fbogert = fbogert at ucsc.edu
+bwoshea = oshea at msu.edu
+mornkr at slac.stanford.edu = me at jihoonkim.org
+kbarrow = kssbarrow at gatech.edu
+kssbarrow at gmail.com = kssbarrow at gatech.edu
+kassbarrow at gmail.com = kssbarrow at gatech.edu
+antoine.strugarek at cea.fr = strugarek at astro.umontreal.ca
+rosen at ucolick.org = alrosen at ucsc.edu
+jzuhone = jzuhone at gmail.com
+karraki at nmsu.edu = karraki at gmail.com
+hckr at eml.cc = astrohckr at gmail.com
+julian3 at illinois.edu = astrohckr at gmail.com
+cosmosquark = bthompson2090 at gmail.com
+chris.m.malone at lanl.gov = chris.m.malone at gmail.com
+jnaiman at ucolick.org = jnaiman
+migueld.deval = miguel at archlinux.net
+slevy at ncsa.illinois.edu = salevy at illinois.edu
+malzraa at gmail.com = kellerbw at mcmaster.ca
+None = convert-repo
+dfenn = df11c at my.fsu.edu
+langmm = langmm.astro at gmail.com
+jmt354 = jmtomlinson95 at gmail.com
+desika = dnarayan at haverford.edu
+Ben Thompson = bthompson2090 at gmail.com
+goldbaum at ucolick.org = ngoldbau at illinois.edu
+ngoldbau at ucsc.edu = ngoldbau at illinois.edu
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 .hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -10,7 +10,9 @@
yt/analysis_modules/halo_finding/rockstar/rockstar_groupies.c
yt/analysis_modules/halo_finding/rockstar/rockstar_interface.c
yt/analysis_modules/ppv_cube/ppv_utils.c
+yt/analysis_modules/photon_simulator/utils.c
yt/frontends/ramses/_ramses_reader.cpp
+yt/frontends/sph/smoothing_kernel.c
yt/geometry/fake_octree.c
yt/geometry/grid_container.c
yt/geometry/grid_visitors.c
@@ -26,34 +28,41 @@
yt/utilities/spatial/ckdtree.c
yt/utilities/lib/alt_ray_tracers.c
yt/utilities/lib/amr_kdtools.c
+yt/utilities/lib/basic_octree.c
yt/utilities/lib/bitarray.c
-yt/utilities/lib/CICDeposit.c
-yt/utilities/lib/ContourFinding.c
-yt/utilities/lib/DepthFirstOctree.c
-yt/utilities/lib/FixedInterpolator.c
+yt/utilities/lib/bounding_volume_hierarchy.c
+yt/utilities/lib/contour_finding.c
+yt/utilities/lib/depth_first_octree.c
+yt/utilities/lib/element_mappings.c
yt/utilities/lib/fortran_reader.c
yt/utilities/lib/freetype_writer.c
yt/utilities/lib/geometry_utils.c
yt/utilities/lib/image_utilities.c
-yt/utilities/lib/Interpolators.c
+yt/utilities/lib/interpolators.c
yt/utilities/lib/kdtree.c
+yt/utilities/lib/line_integral_convolution.c
+yt/utilities/lib/mesh_construction.cpp
+yt/utilities/lib/mesh_intersection.cpp
+yt/utilities/lib/mesh_samplers.cpp
+yt/utilities/lib/mesh_traversal.cpp
yt/utilities/lib/mesh_utilities.c
yt/utilities/lib/misc_utilities.c
-yt/utilities/lib/Octree.c
+yt/utilities/lib/particle_mesh_operations.c
yt/utilities/lib/origami.c
+yt/utilities/lib/particle_mesh_operations.c
yt/utilities/lib/pixelization_routines.c
yt/utilities/lib/png_writer.c
-yt/utilities/lib/PointsInVolume.c
-yt/utilities/lib/QuadTree.c
-yt/utilities/lib/RayIntegrators.c
+yt/utilities/lib/points_in_volume.c
+yt/utilities/lib/quad_tree.c
+yt/utilities/lib/ray_integrators.c
yt/utilities/lib/ragged_arrays.c
-yt/utilities/lib/VolumeIntegrator.c
yt/utilities/lib/grid_traversal.c
yt/utilities/lib/marching_cubes.c
yt/utilities/lib/png_writer.h
yt/utilities/lib/write_array.c
syntax: glob
*.pyc
+*.pyd
.*.swp
*.so
.idea/*
@@ -62,3 +71,4 @@
doc/source/reference/api/generated/*
doc/_temp/*
doc/source/bootcamp/.ipynb_checkpoints/
+dist
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 .python-version
--- /dev/null
+++ b/.python-version
@@ -0,0 +1,1 @@
+2.7.9
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 CONTRIBUTING.rst
--- /dev/null
+++ b/CONTRIBUTING.rst
@@ -0,0 +1,970 @@
+.. This document is rendered in HTML with cross-reference links filled in at
+ http://yt-project.org/doc/developing/
+
+.. _getting-involved:
+
+Getting Involved
+================
+
+There are *lots* of ways to get involved with yt, as a community and as a
+technical system -- not all of them just contributing code, but also
+participating in the community, helping us with designing the websites, adding
+documentation, and sharing your scripts with others.
+
+Coding is only one way to be involved!
+
+Communication Channels
+----------------------
+
+There are five main communication channels for yt:
+
+ * We have an IRC channel, on ``irc.freenode.net`` in ``#yt``.
+ You can connect through our web
+ gateway without any special client, at http://yt-project.org/irc.html .
+ *IRC is the first stop for conversation!*
+ * Many yt developers participate in the yt Slack community. Slack is a free
+ chat service that many teams use to organize their work. You can get an
+ invite to yt's Slack organization by clicking the "Join us @ Slack" button
+ on this page: http://yt-project.org/community.html
+ * `yt-users <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>`_
+ is a relatively high-traffic mailing list where people are encouraged to ask
+ questions about the code, figure things out and so on.
+ * `yt-dev <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_ is
+ a much lower-traffic mailing list designed to focus on discussions of
+ improvements to the code, ideas about planning, development issues, and so
+ on.
+ * `yt-svn <http://lists.spacepope.org/listinfo.cgi/yt-svn-spacepope.org>`_ is
+ the (now-inaccurately titled) mailing list where all pushes to the primary
+ repository are sent.
+
+The easiest way to get involved with yt is to read the mailing lists, hang out
+in IRC or slack chat, and participate. If someone asks a question you know the
+answer to (or have your own question about!) write back and answer it.
+
+If you have an idea about something, suggest it! We not only welcome
+participation, we encourage it.
+
+Documentation
+-------------
+
+The yt documentation is constantly being updated, and it is a task we would very
+much appreciate assistance with. Whether that is adding a section, updating an
+outdated section, contributing typo or grammatical fixes, adding a FAQ, or
+increasing coverage of functionality, it would be very helpful if you wanted to
+help out.
+
+The easiest way to help out is to fork the main yt repository (where the
+documentation lives in the ``doc`` directory in the root of the yt mercurial
+repository) and then make your changes in your own fork. When you are done,
+issue a pull request through the website for your new fork, and we can comment
+back and forth and eventually accept your changes. See :ref:`sharing-changes` for
+more information about contributing your changes to yt on bitbucket.
+
+Gallery Images and Videos
+-------------------------
+
+If you have an image or video you'd like to display in the image or video
+galleries, getting it included it easy! You can either fork the `yt homepage
+repository <http://bitbucket.org/yt_analysis/website>`_ and add it there, or
+email it to us and we'll add it to the `Gallery
+<http://yt-project.org/gallery.html>`_.
+
+We're eager to show off the images and movies you make with yt, so please feel
+free to drop `us <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_
+a line and let us know if you've got something great!
+
+Technical Contributions
+-----------------------
+
+Contributing code is another excellent way to participate -- whether it's
+bug fixes, new features, analysis modules, or a new code frontend. See
+:ref:`creating_frontend` for more details.
+
+The process is pretty simple: fork on BitBucket, make changes, issue a pull
+request. We can then go back and forth with comments in the pull request, but
+usually we end up accepting.
+
+For more information, see :ref:`contributing-code`, where we spell out how to
+get up and running with a development environment, how to commit, and how to
+use BitBucket.
+
+Online Presence
+---------------
+
+Some of these fall under the other items, but if you'd like to help out with
+the website or any of the other ways yt is presented online, please feel free!
+Almost everything is kept in hg repositories on BitBucket, and it is very easy
+to fork and contribute back changes.
+
+Please feel free to dig in and contribute changes.
+
+Word of Mouth
+-------------
+
+If you're using yt and it has increased your productivity, please feel
+encouraged to share that information. Cite our `paper
+<http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_, tell your colleagues,
+and just spread word of mouth. By telling people about your successes, you'll
+help bring more eyes and hands to the table -- in this manner, by increasing
+participation, collaboration, and simply spreading the limits of what the code
+is asked to do, we hope to help scale the utility and capability of yt with the
+community size.
+
+Feel free to `blog <http://blog.yt-project.org/>`_ about, `tweet
+<http://twitter.com/yt_astro>`_ about and talk about what you are up to!
+
+Long-Term Projects
+------------------
+
+There are some wild-eyed, out-there ideas that have been bandied about for the
+future directions of yt -- some of them even written into the mission
+statement. The ultimate goal is to move past simple analysis and visualization
+of data and begin to approach it from the other side, of generating data,
+running solvers. We also hope to increase its ability to act as an in situ
+analysis code, by presenting a unified protocol. Other projects include
+interfacing with ParaView and VisIt, creating a web GUI for running
+simulations, creating a run-tracker that follows simulations in progress, a
+federated database for simulation outputs, and so on and so forth.
+
+yt is an ambitious project. Let's be ambitious together.
+
+yt Community Code of Conduct
+----------------------------
+
+The community of participants in open source
+Scientific projects is made up of members from around the
+globe with a diverse set of skills, personalities, and
+experiences. It is through these differences that our
+community experiences success and continued growth. We
+expect everyone in our community to follow these guidelines
+when interacting with others both inside and outside of our
+community. Our goal is to keep ours a positive, inclusive,
+successful, and growing community.
+
+As members of the community,
+
+- We pledge to treat all people with respect and
+ provide a harassment- and bullying-free environment,
+ regardless of sex, sexual orientation and/or gender
+ identity, disability, physical appearance, body size,
+ race, nationality, ethnicity, and religion. In
+ particular, sexual language and imagery, sexist,
+ racist, or otherwise exclusionary jokes are not
+ appropriate.
+
+- We pledge to respect the work of others by
+ recognizing acknowledgment/citation requests of
+ original authors. As authors, we pledge to be explicit
+ about how we want our own work to be cited or
+ acknowledged.
+
+- We pledge to welcome those interested in joining the
+ community, and realize that including people with a
+ variety of opinions and backgrounds will only serve to
+ enrich our community. In particular, discussions
+ relating to pros/cons of various technologies,
+ programming languages, and so on are welcome, but
+ these should be done with respect, taking proactive
+ measure to ensure that all participants are heard and
+ feel confident that they can freely express their
+ opinions.
+
+- We pledge to welcome questions and answer them
+ respectfully, paying particular attention to those new
+ to the community. We pledge to provide respectful
+ criticisms and feedback in forums, especially in
+ discussion threads resulting from code
+ contributions.
+
+- We pledge to be conscientious of the perceptions of
+ the wider community and to respond to criticism
+ respectfully. We will strive to model behaviors that
+ encourage productive debate and disagreement, both
+ within our community and where we are criticized. We
+ will treat those outside our community with the same
+ respect as people within our community.
+
+- We pledge to help the entire community follow the
+ code of conduct, and to not remain silent when we see
+ violations of the code of conduct. We will take action
+ when members of our community violate this code such as
+ contacting confidential at yt-project.org (all emails sent to
+ this address will be treated with the strictest
+ confidence) or talking privately with the person.
+
+This code of conduct applies to all
+community situations online and offline, including mailing
+lists, forums, social media, conferences, meetings,
+associated social events, and one-to-one interactions.
+
+The yt Community Code of Conduct was adapted from the
+`Astropy Community Code of Conduct
+<http://www.astropy.org/about.html#codeofconduct>`_,
+which was partially inspired by the PSF code of conduct.
+
+.. _contributing-code:
+
+How to Develop yt
+=================
+
+yt is a community project!
+
+We are very happy to accept patches, features, and bugfixes from any member of
+the community! yt is developed using mercurial, primarily because it enables
+very easy and straightforward submission of changesets. We're eager to hear
+from you, and if you are developing yt, we encourage you to subscribe to the
+`developer mailing list
+<http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_. Please feel
+free to hack around, commit changes, and send them upstream.
+
+.. note:: If you already know how to use the `mercurial version control system
+ <http://mercurial-scm.org>`_ and are comfortable with handling it yourself,
+ the quickest way to contribute to yt is to `fork us on BitBucket
+ <http://bitbucket.org/yt_analysis/yt/fork>`_, make your changes, push the
+ changes to your fork and issue a `pull request
+ <http://bitbucket.org/yt_analysis/yt/pull-requests>`_. The rest of this
+ document is just an explanation of how to do that.
+
+See :ref:`code-style-guide` for more information about coding style in yt and
+:ref:`docstrings` for an example docstring. Please read them before hacking on
+the codebase, and feel free to email any of the mailing lists for help with the
+codebase.
+
+Keep in touch, and happy hacking!
+
+.. _open-issues:
+
+Open Issues
+-----------
+
+If you're interested in participating in yt development, take a look at the
+`issue tracker on bitbucket
+<https://bitbucket.org/yt_analysis/yt/issues?milestone=easy?status=new>`_.
+Issues are marked with a milestone of "easy", "moderate", or "difficult"
+depending on the estimated level of difficulty for fixing the issue. While we
+try to triage the issue tracker regularly, it may be the case that issues marked
+"moderate" are actually easier than their milestone label indicates since that
+is the default value.
+
+Here are some predefined issue searches that might be useful:
+
+* Unresolved issues `marked "easy" <https://bitbucket.org/yt_analysis/yt/issues?milestone=easy&status=open&status=new>`_.
+* Unresolved issues `marked "easy" or "moderate" <https://bitbucket.org/yt_analysis/yt/issues?milestone=easy&milestone=moderate&status=open&status=new>`_
+* `All unresolved issues <https://bitbucket.org/yt_analysis/yt/issues?status=open&status=new>`_
+
+Submitting Changes
+------------------
+
+We provide a brief introduction to submitting changes here. yt thrives on the
+strength of its communities (http://arxiv.org/abs/1301.7064 has further
+discussion) and we encourage contributions from any user. While we do not
+discuss version control, mercurial or the advanced usage of BitBucket in detail
+here, we do provide an outline of how to submit changes and we are happy to
+provide further assistance or guidance.
+
+Licensing
++++++++++
+
+yt is `licensed <http://blog.yt-project.org/post/Relicensing.html>`_ under the
+BSD 3-clause license. Versions previous to yt-2.6 were released under the GPLv3.
+
+All contributed code must be BSD-compatible. If you'd rather not license in
+this manner, but still want to contribute, please consider creating an external
+package, which we'll happily link to.
+
+How To Get The Source Code For Editing
+++++++++++++++++++++++++++++++++++++++
+
+yt is hosted on BitBucket, and you can see all of the yt repositories at
+http://bitbucket.org/yt_analysis/. With the yt installation script you should have a
+copy of Mercurial for checking out pieces of code. Make sure you have followed
+the steps above for bootstrapping your development (to assure you have a
+bitbucket account, etc.)
+
+In order to modify the source code for yt, we ask that you make a "fork" of the
+main yt repository on bitbucket. A fork is simply an exact copy of the main
+repository (along with its history) that you will now own and can make
+modifications as you please. You can create a personal fork by visiting the yt
+bitbucket webpage at https://bitbucket.org/yt_analysis/yt/ . After logging in,
+you should see an option near the top right labeled "fork". Click this option,
+and then click the fork repository button on the subsequent page. You now have
+a forked copy of the yt repository for your own personal modification.
+
+This forked copy exists on the bitbucket repository, so in order to access
+it locally, follow the instructions at the top of that webpage for that
+forked repository, namely run at a local command line:
+
+.. code-block:: bash
+
+ $ hg clone http://bitbucket.org/<USER>/<REPOSITORY_NAME>
+
+This downloads that new forked repository to your local machine, so that you
+can access it, read it, make modifications, etc. It will put the repository in
+a local directory of the same name as the repository in the current working
+directory. You can see any past state of the code by using the hg log command.
+For example, the following command would show you the last 5 changesets
+(modifications to the code) that were submitted to that repository.
+
+.. code-block:: bash
+
+ $ cd <REPOSITORY_NAME>
+ $ hg log -l 5
+
+Using the revision specifier (the number or hash identifier next to each
+changeset), you can update the local repository to any past state of the
+code (a previous changeset or version) by executing the command:
+
+.. code-block:: bash
+
+ $ hg up revision_specifier
+
+Lastly, if you want to use this new downloaded version of your yt repository as
+the *active* version of yt on your computer (i.e. the one which is executed when
+you run yt from the command line or the one that is loaded when you do ``import
+yt``), then you must "activate" it using the following commands from within the
+repository directory.
+
+.. code-block:: bash
+
+ $ cd <REPOSITORY_NAME>
+ $ python2.7 setup.py develop
+
+This will rebuild all C modules as well.
+
+.. _reading-source:
+
+How To Read The Source Code
++++++++++++++++++++++++++++
+
+If you just want to *look* at the source code, you may already have it on your
+computer. If you build yt using the install script, the source is available at
+``$YT_DEST/src/yt-hg``. See :ref:`source-installation` for more details about
+to obtain the yt source code if you did not build yt using the install
+script.
+
+The root directory of the yt mercurial repository contains a number of
+subdirectories with different components of the code. Most of the yt source
+code is contained in the yt subdirectory. This directory its self contains
+the following subdirectories:
+
+``frontends``
+ This is where interfaces to codes are created. Within each subdirectory of
+ yt/frontends/ there must exist the following files, even if empty:
+
+ * ``data_structures.py``, where subclasses of AMRGridPatch, Dataset
+ and AMRHierarchy are defined.
+ * ``io.py``, where a subclass of IOHandler is defined.
+ * ``fields.py``, where fields we expect to find in datasets are defined
+ * ``misc.py``, where any miscellaneous functions or classes are defined.
+ * ``definitions.py``, where any definitions specific to the frontend are
+ defined. (i.e., header formats, etc.)
+
+``fields``
+ This is where all of the derived fields that ship with yt are defined.
+
+``geometry``
+ This is where geometric helpler routines are defined. Handlers
+ for grid and oct data, as well as helpers for coordinate transformations
+ can be found here.
+
+``visualization``
+ This is where all visualization modules are stored. This includes plot
+ collections, the volume rendering interface, and pixelization frontends.
+
+``data_objects``
+ All objects that handle data, processed or unprocessed, not explicitly
+ defined as visualization are located in here. This includes the base
+ classes for data regions, covering grids, time series, and so on. This
+ also includes derived fields and derived quantities.
+
+``analysis_modules``
+ This is where all mechanisms for processing data live. This includes
+ things like clump finding, halo profiling, halo finding, and so on. This
+ is something of a catchall, but it serves as a level of greater
+ abstraction that simply data selection and modification.
+
+``gui``
+ This is where all GUI components go. Typically this will be some small
+ tool used for one or two things, which contains a launching mechanism on
+ the command line.
+
+``utilities``
+ All broadly useful code that doesn't clearly fit in one of the other
+ categories goes here.
+
+``extern``
+ Bundled external modules (i.e. code that was not written by one of
+ the yt authors but that yt depends on) lives here.
+
+
+If you're looking for a specific file or function in the yt source code, use
+the unix find command:
+
+.. code-block:: bash
+
+ $ find <DIRECTORY_TREE_TO_SEARCH> -name '<FILENAME>'
+
+The above command will find the FILENAME in any subdirectory in the
+DIRECTORY_TREE_TO_SEARCH. Alternatively, if you're looking for a function
+call or a keyword in an unknown file in a directory tree, try:
+
+.. code-block:: bash
+
+ $ grep -R <KEYWORD_TO_FIND><DIRECTORY_TREE_TO_SEARCH>
+
+This can be very useful for tracking down functions in the yt source.
+
+.. _building-yt:
+
+Building yt
++++++++++++
+
+If you have made changes to any C or Cython (``.pyx``) modules, you have to
+rebuild yt. If your changes have exclusively been to Python modules, you will
+not need to re-build, but (see below) you may need to re-install.
+
+If you are running from a clone that is executable in-place (i.e., has been
+installed via the installation script or you have run ``setup.py develop``) you
+can rebuild these modules by executing:
+
+.. code-block:: bash
+
+ $ python2.7 setup.py develop
+
+If you have previously "installed" via ``setup.py install`` you have to
+re-install:
+
+.. code-block:: bash
+
+ $ python2.7 setup.py install
+
+Only one of these two options is needed.
+
+.. _windows-developing:
+
+Developing yt on Windows
+------------------------
+
+If you plan to develop yt on Windows, it is necessary to use the `MinGW
+<http://www.mingw.org/>`_ gcc compiler that can be installed using the `Anaconda
+Python Distribution <https://store.continuum.io/cshop/anaconda/>`_. The libpython package must be
+installed from Anaconda as well. These can both be installed with a single command:
+
+.. code-block:: bash
+
+ $ conda install libpython mingw
+
+Additionally, the syntax for the setup command is slightly different; you must type:
+
+.. code-block:: bash
+
+ $ python2.7 setup.py build --compiler=mingw32 develop
+
+or
+
+.. code-block:: bash
+
+ $ python2.7 setup.py build --compiler=mingw32 install
+
+.. _requirements-for-code-submission:
+
+Requirements for Code Submission
+--------------------------------
+
+Modifications to the code typically fall into one of three categories, each of
+which have different requirements for acceptance into the code base. These
+requirements are in place for a few reasons -- to make sure that the code is
+maintainable, testable, and that we can easily include information about
+changes in changelogs during the release procedure. (See `YTEP-0008
+<https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0008.html>`_ for more
+detail.)
+
+* New Features
+
+ * New unit tests (possibly new answer tests) (See :ref:`testing`)
+ * Docstrings in the source code for the public API
+ * Addition of new feature to the narrative documentation (See :ref:`writing_documentation`)
+ * Addition of cookbook recipe (See :ref:`writing_documentation`)
+ * Issue created on issue tracker, to ensure this is added to the changelog
+
+* Extension or Breakage of API in Existing Features
+
+ * Update existing narrative docs and docstrings (See :ref:`writing_documentation`)
+ * Update existing cookbook recipes (See :ref:`writing_documentation`)
+ * Modify of create new unit tests (See :ref:`testing`)
+ * Issue created on issue tracker, to ensure this is added to the changelog
+
+* Bug fixes
+
+ * Unit test is encouraged, to ensure breakage does not happen again in the
+ future. (See :ref:`testing`)
+ * Issue created on issue tracker, to ensure this is added to the changelog
+
+When submitting, you will be asked to make sure that your changes meet all of
+these requirements. They are pretty easy to meet, and we're also happy to help
+out with them. In :ref:`code-style-guide` there is a list of handy tips for
+how to structure and write your code.
+
+.. _mercurial-with-yt:
+
+How to Use Mercurial with yt
+----------------------------
+
+If you're new to Mercurial, these three resources are pretty great for learning
+the ins and outs:
+
+* http://hginit.com/
+* http://hgbook.red-bean.com/read/
+* http://mercurial-scm.org/
+* http://mercurial-scm.org/wiki
+
+The commands that are essential for using mercurial include:
+
+* ``hg help`` which provides help for any mercurial command. For example, you
+ can learn more about the ``log`` command by doing ``hg help log``. Other useful
+ topics to use with ``hg help`` are ``hg help glossary``, ``hg help config``,
+ ``hg help extensions``, and ``hg help revsets``.
+* ``hg commit`` which commits changes in the working directory to the
+ repository, creating a new "changeset object."
+* ``hg add`` which adds a new file to be tracked by mercurial. This does
+ not change the working directory.
+* ``hg pull`` which pulls (from an optional path specifier) changeset
+ objects from a remote source. The working directory is not modified.
+* ``hg push`` which sends (to an optional path specifier) changeset objects
+ to a remote source. The working directory is not modified.
+* ``hg log`` which shows a log of all changeset objects in the current
+ repository. Use ``-G`` to show a graph of changeset objects and their
+ relationship.
+* ``hg update`` which (with an optional "revision" specifier) updates the
+ state of the working directory to match a changeset object in the
+ repository.
+* ``hg merge`` which combines two changesets to make a union of their lines
+ of development. This updates the working directory.
+
+We are happy to asnswers questions about mercurial use on our IRC, slack
+chat or on the mailing list to walk you through any troubles you might have.
+Here are some general suggestions for using mercurial with yt:
+
+* Named branches are to be avoided. Try using bookmarks (``see hg help
+ bookmark``) to track work. (`More info about bookmarks is available on the
+ mercurial wiki <http://mercurial-scm.org/wiki/Bookmarks>`_)
+* Make sure you set a username in your ``~/.hgrc`` before you commit any
+ changes! All of the tutorials above will describe how to do this as one of
+ the very first steps.
+* When contributing changes, you might be asked to make a handful of
+ modifications to your source code. We'll work through how to do this with
+ you, and try to make it as painless as possible.
+* Your test may fail automated style checks. See :ref:`code-style-guide` for
+ more information about automatically verifying your code style.
+* Please avoid deleting your yt forks, as that deletes the pull request
+ discussion from process from BitBucket's website, even if your pull request
+ is merged.
+* You should only need one fork. To keep it in sync, you can sync from the
+ website. See Bitbucket's `Blog Post
+ <https://blog.bitbucket.org/2013/02/04/syncing-and-merging-come-to-bitbucket/>`_
+ about this. See :ref:`sharing-changes` for a description of the basic workflow
+ and :ref:`multiple-PRs` for a discussion about what to do when you want to
+ have multiple open pull requests at the same time.
+* If you run into any troubles, stop by IRC (see :ref:`irc`) or the mailing
+ list.
+
+.. _sharing-changes:
+
+Making and Sharing Changes
+--------------------------
+
+The simplest way to submit changes to yt is to do the following:
+
+* Build yt from the mercurial repository
+* Navigate to the root of the yt repository
+* Make some changes and commit them
+* Fork the `yt repository on BitBucket <https://bitbucket.org/yt_analysis/yt>`_
+* Push the changesets to your fork
+* Issue a pull request.
+
+Here's a more detailed flowchart of how to submit changes.
+
+#. If you have used the installation script, the source code for yt can be
+ found in ``$YT_DEST/src/yt-hg``. Alternatively see
+ :ref:`source-installation` for instructions on how to build yt from the
+ mercurial repository. (Below, in :ref:`reading-source`, we describe how to
+ find items of interest.)
+#. Edit the source file you are interested in and
+ test your changes. (See :ref:`testing` for more information.)
+#. Fork yt on BitBucket. (This step only has to be done once.) You can do
+ this at: https://bitbucket.org/yt_analysis/yt/fork. Call this repository
+ yt.
+#. Create a bookmark to track your work. For example: ``hg bookmark
+ my-first-pull-request``
+#. Commit these changes, using ``hg commit``. This can take an argument
+ which is a series of filenames, if you have some changes you do not want
+ to commit.
+#. Remember that this is a large development effort and to keep the code
+ accessible to everyone, good documentation is a must. Add in source code
+ comments for what you are doing. Add in docstrings
+ if you are adding a new function or class or keyword to a function.
+ Add documentation to the appropriate section of the online docs so that
+ people other than yourself know how to use your new code.
+#. If your changes include new functionality or cover an untested area of the
+ code, add a test. (See :ref:`testing` for more information.) Commit
+ these changes as well.
+#. Push your changes to your new fork using the command::
+
+ hg push -B my-first-pull-request https://bitbucket.org/YourUsername/yt/
+
+ Where you should substitute the name of the bookmark you are working on for
+ ``my-first-pull-request``. If you end up doing considerable development, you
+ can set an alias in the file ``.hg/hgrc`` to point to this path.
+
+ .. note::
+ Note that the above approach uses HTTPS as the transfer protocol
+ between your machine and BitBucket. If you prefer to use SSH - or
+ perhaps you're behind a proxy that doesn't play well with SSL via
+ HTTPS - you may want to set up an `SSH key`_ on BitBucket. Then, you use
+ the syntax ``ssh://hg@bitbucket.org/YourUsername/yt``, or equivalent, in
+ place of ``https://bitbucket.org/YourUsername/yt`` in Mercurial commands.
+ For consistency, all commands we list in this document will use the HTTPS
+ protocol.
+
+ .. _SSH key: https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Mercurial
+
+#. Issue a pull request at
+ https://bitbucket.org/YourUsername/yt/pull-request/new
+ A pull request is essentially just asking people to review and accept the
+ modifications you have made to your personal version of the code.
+
+
+During the course of your pull request you may be asked to make changes. These
+changes may be related to style issues, correctness issues, or even requesting
+tests. The process for responding to pull request code review is relatively
+straightforward.
+
+#. Make requested changes, or leave a comment indicating why you don't think
+ they should be made.
+#. Commit those changes to your local repository.
+#. Push the changes to your fork:
+
+ hg push https://bitbucket.org/YourUsername/yt/
+
+#. Your pull request will be automatically updated.
+
+.. _multiple-PRs:
+
+Working with Multiple BitBucket Pull Requests
++++++++++++++++++++++++++++++++++++++++++++++
+
+Once you become active developing for yt, you may be working on
+various aspects of the code or bugfixes at the same time. Currently,
+BitBucket's *modus operandi* for pull requests automatically updates
+your active pull request with every ``hg push`` of commits that are a
+descendant of the head of your pull request. In a normal workflow,
+this means that if you have an active pull request, make some changes
+locally for, say, an unrelated bugfix, then push those changes back to
+your fork in the hopes of creating a *new* pull request, you'll
+actually end up updating your current pull request!
+
+There are a few ways around this feature of BitBucket that will allow
+for multiple pull requests to coexist; we outline one such method
+below. We assume that you have a fork of yt at
+``http://bitbucket.org/YourUsername/Your_yt`` (see
+:ref:`sharing-changes` for instructions on creating a fork) and that
+you have an active pull request to the main repository.
+
+The main issue with starting another pull request is to make sure that
+your push to BitBucket doesn't go to the same head as your
+existing pull request and trigger BitBucket's auto-update feature.
+Here's how to get your local repository away from your current pull
+request head using `revsets <http://www.selenic.com/hg/help/revsets>`_
+and your ``hgrc`` file:
+
+#. Set up a Mercurial path for the main yt repository (note this is a convenience
+ step and only needs to be done once). Add the following to your
+ ``Your_yt/.hg/hgrc``::
+
+ [paths]
+ upstream = https://bitbucket.org/yt_analysis/yt
+
+ This will create a path called ``upstream`` that is aliased to the URL of the
+ main yt repository.
+#. Now we'll use revsets_ to update your local repository to the tip of the
+ ``upstream`` path:
+
+ .. code-block:: bash
+
+ $ hg pull upstream
+ $ hg update -r "remote(yt, 'upstream')"
+
+After the above steps, your local repository should be at the current head of
+the ``yt`` branch in the main yt repository. If you find yourself doing this a
+lot, it may be worth aliasing this task in your ``hgrc`` file by adding
+something like::
+
+ [alias]
+ ytupdate = update -r "remote(yt, 'upstream')"
+
+And then you can just issue ``hg ytupdate`` to get at the current head of the
+``yt`` branch on main yt repository.
+
+Make sure you are on the branch you want to be on, and then you can make changes
+and ``hg commit`` them. If you prefer working with `bookmarks
+<http://mercurial-scm.org/wiki/Bookmarks>`_, you may want to make a bookmark
+before committing your changes, such as ``hg bookmark mybookmark``.
+
+To push your changes on a bookmark to bitbucket, you can issue the following
+command:
+
+.. code-block:: bash
+
+ $ hg push -B myfeature https://bitbucket.org/YourUsername/Your_yt
+
+The ``-B`` means "publish my bookmark, the changeset the bookmark is pointing
+at, and any ancestors of that changeset that aren't already on the remote
+server".
+
+To push to your fork on BitBucket if you didn't use a bookmark, you issue the
+following:
+
+.. code-block:: bash
+
+ $ hg push -r . -f https://bitbucket.org/YourUsername/Your_yt
+
+The ``-r .`` means "push only the commit I'm standing on and any ancestors."
+The ``-f`` is to force Mecurial to do the push since we are creating a new
+remote head without a bookmark.
+
+You can then go to the BitBucket interface and issue a new pull request based on
+your last changes, as usual.
+
+.. _code-style-guide:
+
+Coding Style Guide
+==================
+
+Automatically checking code style
+---------------------------------
+
+Below are a list of rules for coding style in yt. Some of these rules are
+suggestions are not explicitly enforced, while some are enforced via automated
+testing. The yt project uses a subset of the rules checked by ``flake8`` to
+verify our code. The ``flake8`` tool is a combination of the ``pyflakes`` and
+``pep8`` tools. To check the coding style of your contributions locally you will
+need to install the ``flake8`` tool from ``pip``:
+
+.. code-block:: bash
+
+ $ pip install flake8
+
+And then navigate to the root of the yt repository and run ``flake8`` on the
+``yt`` folder:
+
+.. code-block:: bash
+
+ $ cd $YT_HG
+ $ flake8 ./yt
+
+This will print out any ``flake8`` errors or warnings that your newly added code
+triggers. The errors will be in your newly added code because we have already
+cleaned up the rest of the yt codebase of the errors and warnings detected by
+the `flake8` tool. Note that this will only trigger a subset of the `full flake8
+error and warning list
+<http://flake8.readthedocs.org/en/latest/warnings.html>`_, since we explicitly
+blacklist a large number of the full list of rules that are checked by
+``flake8`` by default.
+
+Source code style guide
+-----------------------
+
+ * In general, follow PEP-8 guidelines.
+ http://www.python.org/dev/peps/pep-0008/
+ * Classes are ``ConjoinedCapitals``, methods and functions are
+ ``lowercase_with_underscores``.
+ * Use 4 spaces, not tabs, to represent indentation.
+ * Line widths should not be more than 80 characters.
+ * Do not use nested classes unless you have a very good reason to, such as
+ requiring a namespace or class-definition modification. Classes should live
+ at the top level. ``__metaclass__`` is exempt from this.
+ * Do not use unnecessary parenthesis in conditionals. ``if((something) and
+ (something_else))`` should be rewritten as
+ ``if something and something_else``. Python is more forgiving than C.
+ * Avoid copying memory when possible. For example, don't do
+ ``a = a.reshape(3,4)`` when ``a.shape = (3,4)`` will do, and ``a = a * 3``
+ should be ``np.multiply(a, 3, a)``.
+ * In general, avoid all double-underscore method names: ``__something`` is
+ usually unnecessary.
+ * When writing a subclass, use the super built-in to access the super class,
+ rather than explicitly. Ex: ``super(SpecialGridSubclass, self).__init__()``
+ rather than ``SpecialGrid.__init__()``.
+ * Docstrings should describe input, output, behavior, and any state changes
+ that occur on an object. See :ref:`docstrings` below for a fiducial example
+ of a docstring.
+ * Use only one top-level import per line. Unless there is a good reason not to,
+ imports should happen at the top of the file, after the copyright blurb.
+ * Never compare with ``True`` or ``False`` using ``==`` or ``!=``, always use
+ ``is`` or ``is not``.
+ * If you are comparing with a numpy boolean array, just refer to the array.
+ Ex: do ``np.all(array)`` instead of ``np.all(array == True)``.
+ * Never comapre with None using ``==`` or ``!=``, use ``is None`` or
+ ``is not None``.
+ * Use ``statement is not True`` instead of ``not statement is True``
+ * Only one statement per line, do not use semicolons to put two or more
+ statements on a single line.
+ * Only declare local variables if they will be used later. If you do not use the
+ return value of a function, do not store it in a variable.
+ * Add tests for new functionality. When fixing a bug, consider adding a test to
+ prevent the bug from recurring.
+
+API Style Guide
+---------------
+
+ * Do not use ``from some_module import *``
+ * Internally, only import from source files directly -- instead of:
+
+ ``from yt.visualization.api import ProjectionPlot``
+
+ do:
+
+ ``from yt.visualization.plot_window import ProjectionPlot``
+
+ * Import symbols from the module where they are defined, avoid transitive
+ imports.
+ * Import standard library modules, functions, and classes from builtins, do not
+ import them from other yt files.
+ * Numpy is to be imported as ``np``.
+ * Do not use too many keyword arguments. If you have a lot of keyword
+ arguments, then you are doing too much in ``__init__`` and not enough via
+ parameter setting.
+ * In function arguments, place spaces before commas. ``def something(a,b,c)``
+ should be ``def something(a, b, c)``.
+ * Don't create a new class to replicate the functionality of an old class --
+ replace the old class. Too many options makes for a confusing user
+ experience.
+ * Parameter files external to yt are a last resort.
+ * The usage of the ``**kwargs`` construction should be avoided. If they cannot
+ be avoided, they must be explained, even if they are only to be passed on to
+ a nested function.
+
+.. _docstrings:
+
+Docstrings
+----------
+
+The following is an example docstring. You can use it as a template for
+docstrings in your code and as a guide for how we expect docstrings to look and
+the level of detail we are looking for. Note that we use NumPy style docstrings
+written in `Sphinx restructured text format <http://sphinx-doc.org/rest.html>`_.
+
+.. code-block:: rest
+
+ r"""A one-line summary that does not use variable names or the
+ function name.
+
+ Several sentences providing an extended description. Refer to
+ variables using back-ticks, e.g. ``var``.
+
+ Parameters
+ ----------
+ var1 : array_like
+ Array_like means all those objects -- lists, nested lists, etc. --
+ that can be converted to an array. We can also refer to
+ variables like ``var1``.
+ var2 : int
+ The type above can either refer to an actual Python type
+ (e.g. ``int``), or describe the type of the variable in more
+ detail, e.g. ``(N,) ndarray`` or ``array_like``.
+ Long_variable_name : {'hi', 'ho'}, optional
+ Choices in brackets, default first when optional.
+
+ Returns
+ -------
+ describe : type
+ Explanation
+ output : type
+ Explanation
+ tuple : type
+ Explanation
+ items : type
+ even more explaining
+
+ Other Parameters
+ ----------------
+ only_seldom_used_keywords : type
+ Explanation
+ common_parameters_listed_above : type
+ Explanation
+
+ Raises
+ ------
+ BadException
+ Because you shouldn't have done that.
+
+ See Also
+ --------
+ otherfunc : relationship (optional)
+ newfunc : Relationship (optional), which could be fairly long, in which
+ case the line wraps here.
+ thirdfunc, fourthfunc, fifthfunc
+
+ Notes
+ -----
+ Notes about the implementation algorithm (if needed).
+
+ This can have multiple paragraphs.
+
+ You may include some math:
+
+ .. math:: X(e^{j\omega } ) = x(n)e^{ - j\omega n}
+
+ And even use a greek symbol like :math:`omega` inline.
+
+ References
+ ----------
+ Cite the relevant literature, e.g. [1]_. You may also cite these
+ references in the notes section above.
+
+ .. [1] O. McNoleg, "The integration of GIS, remote sensing,
+ expert systems and adaptive co-kriging for environmental habitat
+ modelling of the Highland Haggis using object-oriented, fuzzy-logic
+ and neural-network techniques," Computers & Geosciences, vol. 22,
+ pp. 585-588, 1996.
+
+ Examples
+ --------
+ These are written in doctest format, and should illustrate how to
+ use the function. Use the variables 'ds' for the dataset, 'pc' for
+ a plot collection, 'c' for a center, and 'L' for a vector.
+
+ >>> a=[1,2,3]
+ >>> print [x + 3 for x in a]
+ [4, 5, 6]
+ >>> print "a\n\nb"
+ a
+ b
+
+ """
+
+Variable Names and Enzo-isms
+----------------------------
+Avoid Enzo-isms. This includes but is not limited to:
+
+ * Hard-coding parameter names that are the same as those in Enzo. The
+ following translation table should be of some help. Note that the
+ parameters are now properties on a ``Dataset`` subclass: you access them
+ like ds.refine_by .
+
+ - ``RefineBy `` => `` refine_by``
+ - ``TopGridRank `` => `` dimensionality``
+ - ``TopGridDimensions `` => `` domain_dimensions``
+ - ``InitialTime `` => `` current_time``
+ - ``DomainLeftEdge `` => `` domain_left_edge``
+ - ``DomainRightEdge `` => `` domain_right_edge``
+ - ``CurrentTimeIdentifier `` => `` unique_identifier``
+ - ``CosmologyCurrentRedshift `` => `` current_redshift``
+ - ``ComovingCoordinates `` => `` cosmological_simulation``
+ - ``CosmologyOmegaMatterNow `` => `` omega_matter``
+ - ``CosmologyOmegaLambdaNow `` => `` omega_lambda``
+ - ``CosmologyHubbleConstantNow `` => `` hubble_constant``
+
+ * Do not assume that the domain runs from 0 .. 1. This is not true
+ everywhere.
+ * Variable names should be short but descriptive.
+ * No globals!
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 CREDITS
--- a/CREDITS
+++ b/CREDITS
@@ -4,32 +4,49 @@
Tom Abel (tabel at stanford.edu)
Gabriel Altay (gabriel.altay at gmail.com)
Kenza Arraki (karraki at gmail.com)
+ Kirk Barrow (kssbarrow at gatech.edu)
+ Ricarda Beckmann (Ricarda.Beckmann at astro.ox.ac.uk)
Elliott Biondo (biondo at wisc.edu)
Alex Bogert (fbogert at ucsc.edu)
+ André-Patrick Bubel (code at andre-bubel.de)
Pengfei Chen (madcpf at gmail.com)
+ Yi-Hao Chen (yihaochentw at gmail.com)
David Collins (dcollins4096 at gmail.com)
Brian Crosby (crosby.bd at gmail.com)
Andrew Cunningham (ajcunn at gmail.com)
Miguel de Val-Borro (miguel.deval at gmail.com)
+ Bili Dong (qobilidop at gmail.com)
+ Nicholas Earl (nchlsearl at gmail.com)
Hilary Egan (hilaryye at gmail.com)
+ Daniel Fenn (df11c at my.fsu.edu)
John Forces (jforbes at ucolick.org)
+ Adam Ginsburg (keflavich at gmail.com)
Sam Geen (samgeen at gmail.com)
Nathan Goldbaum (goldbaum at ucolick.org)
+ William Gray (graywilliamj at gmail.com)
Markus Haider (markus.haider at uibk.ac.at)
Eric Hallman (hallman13 at gmail.com)
+ David Hannasch (David.A.Hannasch at gmail.com)
Cameron Hummels (chummels at gmail.com)
+ Anni Järvenpää (anni.jarvenpaa at gmail.com)
+ Allyson Julian (astrohckr at gmail.com)
Christian Karch (chiffre at posteo.de)
+ Maximilian Katz (maximilian.katz at stonybrook.edu)
Ben W. Keller (kellerbw at mcmaster.ca)
Ji-hoon Kim (me at jihoonkim.org)
Steffen Klemer (sklemer at phys.uni-goettingen.de)
Kacper Kowalik (xarthisius.kk at gmail.com)
Mark Krumholz (mkrumhol at ucsc.edu)
Michael Kuhlen (mqk at astro.berkeley.edu)
+ Meagan Lang (langmm.astro at gmail.com)
+ Doris Lee (dorislee at berkeley.edu)
Eve Lee (elee at cita.utoronto.ca)
Sam Leitner (sam.leitner at gmail.com)
+ Stuart Levy (salevy at illinois.edu)
Yuan Li (yuan at astro.columbia.edu)
Chris Malone (chris.m.malone at gmail.com)
Josh Maloney (joshua.moloney at colorado.edu)
+ Jonah Miller (jonah.maxwell.miller at gmail.com)
Chris Moody (cemoody at ucsc.edu)
Stuart Mumford (stuart at mumford.me.uk)
Andrew Myers (atmyers at astro.berkeley.edu)
@@ -44,7 +61,9 @@
Mark Richardson (Mark.L.Richardson at asu.edu)
Thomas Robitaille (thomas.robitaille at gmail.com)
Anna Rosen (rosen at ucolick.org)
+ Chuck Rozhon (rozhon2 at illinois.edu)
Douglas Rudd (drudd at uchicago.edu)
+ Hsi-Yu Schive (hyschive at gmail.com)
Anthony Scopatz (scopatz at gmail.com)
Noel Scudder (noel.scudder at stonybrook.edu)
Pat Shriwise (shriwise at wisc.edu)
@@ -59,6 +78,8 @@
Ji Suoqing (jisuoqing at gmail.com)
Elizabeth Tasker (tasker at astro1.sci.hokudai.ac.jp)
Benjamin Thompson (bthompson2090 at gmail.com)
+ Robert Thompson (rthompsonj at gmail.com)
+ Joseph Tomlinson (jmtomlinson95 at gmail.com)
Stephanie Tonnesen (stonnes at gmail.com)
Matthew Turk (matthewturk at gmail.com)
Rich Wagner (rwagner at physics.ucsd.edu)
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 MANIFEST.in
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -1,14 +1,16 @@
-include distribute_setup.py README* CREDITS COPYING.txt CITATION
-recursive-include yt/gui/reason/html *.html *.png *.ico *.js *.gif *.css
-recursive-include yt *.py *.pyx *.pxd *.h README* *.txt LICENSE*
-recursive-include doc *.rst *.txt *.py *.ipynb *.png *.jpg *.css *.inc *.html
+include README* CREDITS COPYING.txt CITATION requirements.txt optional-requirements.txt setupext.py CONTRIBUTING.rst
+include yt/visualization/mapserver/html/map_index.html
+include yt/visualization/mapserver/html/leaflet/*.css
+include yt/visualization/mapserver/html/leaflet/*.js
+include yt/visualization/mapserver/html/leaflet/images/*.png
+exclude scripts/pr_backport.py
+recursive-include yt *.py *.pyx *.pxd *.h README* *.txt LICENSE* *.cu
+recursive-include doc *.rst *.txt *.py *.ipynb *.png *.jpg *.css *.html
recursive-include doc *.h *.c *.sh *.svgz *.pdf *.svg *.pyx
include doc/README doc/activate doc/activate.csh doc/cheatsheet.tex
include doc/extensions/README doc/Makefile
prune doc/source/reference/api/generated
-prune doc/build/
+prune doc/build
recursive-include yt/analysis_modules/halo_finding/rockstar *.py *.pyx
+recursive-include yt/visualization/volume_rendering/shaders *.fragmentshader *.vertexshader
prune yt/frontends/_skeleton
-prune tests
-graft yt/gui/reason/html/resources
-exclude clean.sh .hgchurn
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 README
--- a/README
+++ b/README
@@ -21,3 +21,4 @@
ways to help development, please visit our website.
Enjoy!
+
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 clean.sh
--- a/clean.sh
+++ b/clean.sh
@@ -1,4 +1,1 @@
-find . -name "*.so" -exec rm -v {} \;
-find . -name "*.pyc" -exec rm -v {} \;
-find . -name "__config__.py" -exec rm -v {} \;
-rm -rvf build dist
+hg --config extensions.purge= purge --all yt
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 distribute_setup.py
--- a/distribute_setup.py
+++ /dev/null
@@ -1,541 +0,0 @@
-#!python
-"""Bootstrap distribute installation
-
-If you want to use setuptools in your package's setup.py, just include this
-file in the same directory with it, and add this to the top of your setup.py::
-
- from distribute_setup import use_setuptools
- use_setuptools()
-
-If you want to require a specific version of setuptools, set a download
-mirror, or use an alternate download directory, you can do so by supplying
-the appropriate options to ``use_setuptools()``.
-
-This file can also be run as a script to install or upgrade setuptools.
-"""
-import os
-import shutil
-import sys
-import time
-import fnmatch
-import tempfile
-import tarfile
-import optparse
-
-from distutils import log
-
-try:
- from site import USER_SITE
-except ImportError:
- USER_SITE = None
-
-try:
- import subprocess
-
- def _python_cmd(*args):
- args = (sys.executable,) + args
- return subprocess.call(args) == 0
-
-except ImportError:
- # will be used for python 2.3
- def _python_cmd(*args):
- args = (sys.executable,) + args
- # quoting arguments if windows
- if sys.platform == 'win32':
- def quote(arg):
- if ' ' in arg:
- return '"%s"' % arg
- return arg
- args = [quote(arg) for arg in args]
- return os.spawnl(os.P_WAIT, sys.executable, *args) == 0
-
-DEFAULT_VERSION = "0.6.32"
-DEFAULT_URL = "http://pypi.python.org/packages/source/d/distribute/"
-SETUPTOOLS_FAKED_VERSION = "0.6c11"
-
-SETUPTOOLS_PKG_INFO = """\
-Metadata-Version: 1.0
-Name: setuptools
-Version: %s
-Summary: xxxx
-Home-page: xxx
-Author: xxx
-Author-email: xxx
-License: xxx
-Description: xxx
-""" % SETUPTOOLS_FAKED_VERSION
-
-
-def _install(tarball, install_args=()):
- # extracting the tarball
- tmpdir = tempfile.mkdtemp()
- log.warn('Extracting in %s', tmpdir)
- old_wd = os.getcwd()
- try:
- os.chdir(tmpdir)
- tar = tarfile.open(tarball)
- _extractall(tar)
- tar.close()
-
- # going in the directory
- subdir = os.path.join(tmpdir, os.listdir(tmpdir)[0])
- os.chdir(subdir)
- log.warn('Now working in %s', subdir)
-
- # installing
- log.warn('Installing Distribute')
- if not _python_cmd('setup.py', 'install', *install_args):
- log.warn('Something went wrong during the installation.')
- log.warn('See the error message above.')
- # exitcode will be 2
- return 2
- finally:
- os.chdir(old_wd)
- shutil.rmtree(tmpdir)
-
-
-def _build_egg(egg, tarball, to_dir):
- # extracting the tarball
- tmpdir = tempfile.mkdtemp()
- log.warn('Extracting in %s', tmpdir)
- old_wd = os.getcwd()
- try:
- os.chdir(tmpdir)
- tar = tarfile.open(tarball)
- _extractall(tar)
- tar.close()
-
- # going in the directory
- subdir = os.path.join(tmpdir, os.listdir(tmpdir)[0])
- os.chdir(subdir)
- log.warn('Now working in %s', subdir)
-
- # building an egg
- log.warn('Building a Distribute egg in %s', to_dir)
- _python_cmd('setup.py', '-q', 'bdist_egg', '--dist-dir', to_dir)
-
- finally:
- os.chdir(old_wd)
- shutil.rmtree(tmpdir)
- # returning the result
- log.warn(egg)
- if not os.path.exists(egg):
- raise IOError('Could not build the egg.')
-
-
-def _do_download(version, download_base, to_dir, download_delay):
- egg = os.path.join(to_dir, 'distribute-%s-py%d.%d.egg'
- % (version, sys.version_info[0], sys.version_info[1]))
- if not os.path.exists(egg):
- tarball = download_setuptools(version, download_base,
- to_dir, download_delay)
- _build_egg(egg, tarball, to_dir)
- sys.path.insert(0, egg)
- import setuptools
- setuptools.bootstrap_install_from = egg
-
-
-def use_setuptools(version=DEFAULT_VERSION, download_base=DEFAULT_URL,
- to_dir=os.curdir, download_delay=15, no_fake=True):
- # making sure we use the absolute path
- to_dir = os.path.abspath(to_dir)
- was_imported = 'pkg_resources' in sys.modules or \
- 'setuptools' in sys.modules
- try:
- try:
- import pkg_resources
- if not hasattr(pkg_resources, '_distribute'):
- if not no_fake:
- _fake_setuptools()
- raise ImportError
- except ImportError:
- return _do_download(version, download_base, to_dir, download_delay)
- try:
- pkg_resources.require("distribute>=" + version)
- return
- except pkg_resources.VersionConflict:
- e = sys.exc_info()[1]
- if was_imported:
- sys.stderr.write(
- "The required version of distribute (>=%s) is not available,\n"
- "and can't be installed while this script is running. Please\n"
- "install a more recent version first, using\n"
- "'easy_install -U distribute'."
- "\n\n(Currently using %r)\n" % (version, e.args[0]))
- sys.exit(2)
- else:
- del pkg_resources, sys.modules['pkg_resources'] # reload ok
- return _do_download(version, download_base, to_dir,
- download_delay)
- except pkg_resources.DistributionNotFound:
- return _do_download(version, download_base, to_dir,
- download_delay)
- finally:
- if not no_fake:
- _create_fake_setuptools_pkg_info(to_dir)
-
-
-def download_setuptools(version=DEFAULT_VERSION, download_base=DEFAULT_URL,
- to_dir=os.curdir, delay=15):
- """Download distribute from a specified location and return its filename
-
- `version` should be a valid distribute version number that is available
- as an egg for download under the `download_base` URL (which should end
- with a '/'). `to_dir` is the directory where the egg will be downloaded.
- `delay` is the number of seconds to pause before an actual download
- attempt.
- """
- # making sure we use the absolute path
- to_dir = os.path.abspath(to_dir)
- try:
- from urllib.request import urlopen
- except ImportError:
- from urllib2 import urlopen
- tgz_name = "distribute-%s.tar.gz" % version
- url = download_base + tgz_name
- saveto = os.path.join(to_dir, tgz_name)
- src = dst = None
- if not os.path.exists(saveto): # Avoid repeated downloads
- try:
- log.warn("Downloading %s", url)
- src = urlopen(url)
- # Read/write all in one block, so we don't create a corrupt file
- # if the download is interrupted.
- data = src.read()
- dst = open(saveto, "wb")
- dst.write(data)
- finally:
- if src:
- src.close()
- if dst:
- dst.close()
- return os.path.realpath(saveto)
-
-
-def _no_sandbox(function):
- def __no_sandbox(*args, **kw):
- try:
- from setuptools.sandbox import DirectorySandbox
- if not hasattr(DirectorySandbox, '_old'):
- def violation(*args):
- pass
- DirectorySandbox._old = DirectorySandbox._violation
- DirectorySandbox._violation = violation
- patched = True
- else:
- patched = False
- except ImportError:
- patched = False
-
- try:
- return function(*args, **kw)
- finally:
- if patched:
- DirectorySandbox._violation = DirectorySandbox._old
- del DirectorySandbox._old
-
- return __no_sandbox
-
-
-def _patch_file(path, content):
- """Will backup the file then patch it"""
- existing_content = open(path).read()
- if existing_content == content:
- # already patched
- log.warn('Already patched.')
- return False
- log.warn('Patching...')
- _rename_path(path)
- f = open(path, 'w')
- try:
- f.write(content)
- finally:
- f.close()
- return True
-
-_patch_file = _no_sandbox(_patch_file)
-
-
-def _same_content(path, content):
- return open(path).read() == content
-
-
-def _rename_path(path):
- new_name = path + '.OLD.%s' % time.time()
- log.warn('Renaming %s to %s', path, new_name)
- os.rename(path, new_name)
- return new_name
-
-
-def _remove_flat_installation(placeholder):
- if not os.path.isdir(placeholder):
- log.warn('Unknown installation at %s', placeholder)
- return False
- found = False
- for file in os.listdir(placeholder):
- if fnmatch.fnmatch(file, 'setuptools*.egg-info'):
- found = True
- break
- if not found:
- log.warn('Could not locate setuptools*.egg-info')
- return
-
- log.warn('Moving elements out of the way...')
- pkg_info = os.path.join(placeholder, file)
- if os.path.isdir(pkg_info):
- patched = _patch_egg_dir(pkg_info)
- else:
- patched = _patch_file(pkg_info, SETUPTOOLS_PKG_INFO)
-
- if not patched:
- log.warn('%s already patched.', pkg_info)
- return False
- # now let's move the files out of the way
- for element in ('setuptools', 'pkg_resources.py', 'site.py'):
- element = os.path.join(placeholder, element)
- if os.path.exists(element):
- _rename_path(element)
- else:
- log.warn('Could not find the %s element of the '
- 'Setuptools distribution', element)
- return True
-
-_remove_flat_installation = _no_sandbox(_remove_flat_installation)
-
-
-def _after_install(dist):
- log.warn('After install bootstrap.')
- placeholder = dist.get_command_obj('install').install_purelib
- _create_fake_setuptools_pkg_info(placeholder)
-
-
-def _create_fake_setuptools_pkg_info(placeholder):
- if not placeholder or not os.path.exists(placeholder):
- log.warn('Could not find the install location')
- return
- pyver = '%s.%s' % (sys.version_info[0], sys.version_info[1])
- setuptools_file = 'setuptools-%s-py%s.egg-info' % \
- (SETUPTOOLS_FAKED_VERSION, pyver)
- pkg_info = os.path.join(placeholder, setuptools_file)
- if os.path.exists(pkg_info):
- log.warn('%s already exists', pkg_info)
- return
-
- log.warn('Creating %s', pkg_info)
- try:
- f = open(pkg_info, 'w')
- except EnvironmentError:
- log.warn("Don't have permissions to write %s, skipping", pkg_info)
- return
- try:
- f.write(SETUPTOOLS_PKG_INFO)
- finally:
- f.close()
-
- pth_file = os.path.join(placeholder, 'setuptools.pth')
- log.warn('Creating %s', pth_file)
- f = open(pth_file, 'w')
- try:
- f.write(os.path.join(os.curdir, setuptools_file))
- finally:
- f.close()
-
-_create_fake_setuptools_pkg_info = _no_sandbox(
- _create_fake_setuptools_pkg_info
-)
-
-
-def _patch_egg_dir(path):
- # let's check if it's already patched
- pkg_info = os.path.join(path, 'EGG-INFO', 'PKG-INFO')
- if os.path.exists(pkg_info):
- if _same_content(pkg_info, SETUPTOOLS_PKG_INFO):
- log.warn('%s already patched.', pkg_info)
- return False
- _rename_path(path)
- os.mkdir(path)
- os.mkdir(os.path.join(path, 'EGG-INFO'))
- pkg_info = os.path.join(path, 'EGG-INFO', 'PKG-INFO')
- f = open(pkg_info, 'w')
- try:
- f.write(SETUPTOOLS_PKG_INFO)
- finally:
- f.close()
- return True
-
-_patch_egg_dir = _no_sandbox(_patch_egg_dir)
-
-
-def _before_install():
- log.warn('Before install bootstrap.')
- _fake_setuptools()
-
-
-def _under_prefix(location):
- if 'install' not in sys.argv:
- return True
- args = sys.argv[sys.argv.index('install') + 1:]
- for index, arg in enumerate(args):
- for option in ('--root', '--prefix'):
- if arg.startswith('%s=' % option):
- top_dir = arg.split('root=')[-1]
- return location.startswith(top_dir)
- elif arg == option:
- if len(args) > index:
- top_dir = args[index + 1]
- return location.startswith(top_dir)
- if arg == '--user' and USER_SITE is not None:
- return location.startswith(USER_SITE)
- return True
-
-
-def _fake_setuptools():
- log.warn('Scanning installed packages')
- try:
- import pkg_resources
- except ImportError:
- # we're cool
- log.warn('Setuptools or Distribute does not seem to be installed.')
- return
- ws = pkg_resources.working_set
- try:
- setuptools_dist = ws.find(
- pkg_resources.Requirement.parse('setuptools', replacement=False)
- )
- except TypeError:
- # old distribute API
- setuptools_dist = ws.find(
- pkg_resources.Requirement.parse('setuptools')
- )
-
- if setuptools_dist is None:
- log.warn('No setuptools distribution found')
- return
- # detecting if it was already faked
- setuptools_location = setuptools_dist.location
- log.warn('Setuptools installation detected at %s', setuptools_location)
-
- # if --root or --preix was provided, and if
- # setuptools is not located in them, we don't patch it
- if not _under_prefix(setuptools_location):
- log.warn('Not patching, --root or --prefix is installing Distribute'
- ' in another location')
- return
-
- # let's see if its an egg
- if not setuptools_location.endswith('.egg'):
- log.warn('Non-egg installation')
- res = _remove_flat_installation(setuptools_location)
- if not res:
- return
- else:
- log.warn('Egg installation')
- pkg_info = os.path.join(setuptools_location, 'EGG-INFO', 'PKG-INFO')
- if (os.path.exists(pkg_info) and
- _same_content(pkg_info, SETUPTOOLS_PKG_INFO)):
- log.warn('Already patched.')
- return
- log.warn('Patching...')
- # let's create a fake egg replacing setuptools one
- res = _patch_egg_dir(setuptools_location)
- if not res:
- return
- log.warn('Patching complete.')
- _relaunch()
-
-
-def _relaunch():
- log.warn('Relaunching...')
- # we have to relaunch the process
- # pip marker to avoid a relaunch bug
- _cmd1 = ['-c', 'install', '--single-version-externally-managed']
- _cmd2 = ['-c', 'install', '--record']
- if sys.argv[:3] == _cmd1 or sys.argv[:3] == _cmd2:
- sys.argv[0] = 'setup.py'
- args = [sys.executable] + sys.argv
- sys.exit(subprocess.call(args))
-
-
-def _extractall(self, path=".", members=None):
- """Extract all members from the archive to the current working
- directory and set owner, modification time and permissions on
- directories afterwards. `path' specifies a different directory
- to extract to. `members' is optional and must be a subset of the
- list returned by getmembers().
- """
- import copy
- import operator
- from tarfile import ExtractError
- directories = []
-
- if members is None:
- members = self
-
- for tarinfo in members:
- if tarinfo.isdir():
- # Extract directories with a safe mode.
- directories.append(tarinfo)
- tarinfo = copy.copy(tarinfo)
- tarinfo.mode = 448 # decimal for oct 0700
- self.extract(tarinfo, path)
-
- # Reverse sort directories.
- if sys.version_info < (2, 4):
- def sorter(dir1, dir2):
- return cmp(dir1.name, dir2.name)
- directories.sort(sorter)
- directories.reverse()
- else:
- directories.sort(key=operator.attrgetter('name'), reverse=True)
-
- # Set correct owner, mtime and filemode on directories.
- for tarinfo in directories:
- dirpath = os.path.join(path, tarinfo.name)
- try:
- self.chown(tarinfo, dirpath)
- self.utime(tarinfo, dirpath)
- self.chmod(tarinfo, dirpath)
- except ExtractError:
- e = sys.exc_info()[1]
- if self.errorlevel > 1:
- raise
- else:
- self._dbg(1, "tarfile: %s" % e)
-
-
-def _build_install_args(options):
- """
- Build the arguments to 'python setup.py install' on the distribute package
- """
- install_args = []
- if options.user_install:
- if sys.version_info < (2, 6):
- log.warn("--user requires Python 2.6 or later")
- raise SystemExit(1)
- install_args.append('--user')
- return install_args
-
-def _parse_args():
- """
- Parse the command line for options
- """
- parser = optparse.OptionParser()
- parser.add_option(
- '--user', dest='user_install', action='store_true', default=False,
- help='install in user site package (requires Python 2.6 or later)')
- parser.add_option(
- '--download-base', dest='download_base', metavar="URL",
- default=DEFAULT_URL,
- help='alternative URL from where to download the distribute package')
- options, args = parser.parse_args()
- # positional arguments are ignored
- return options
-
-def main(version=DEFAULT_VERSION):
- """Install or upgrade setuptools and EasyInstall"""
- options = _parse_args()
- tarball = download_setuptools(download_base=options.download_base)
- return _install(tarball, _build_install_args(options))
-
-if __name__ == '__main__':
- sys.exit(main())
diff -r 69e32dee2a2e7bedd85f5aadcbdc5e78668dfeab -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 doc/README
--- a/doc/README
+++ b/doc/README
@@ -7,4 +7,4 @@
Because the documentation requires a number of dependencies, we provide
pre-built versions online, accessible here:
-http://yt-project.org/docs/dev-3.0/
+http://yt-project.org/docs/dev/
This diff is so big that we needed to truncate the remainder.
https://bitbucket.org/yt_analysis/yt/commits/e6627bf8a52d/
Changeset: e6627bf8a52d
Branch: yt
User: jzuhone
Date: 2016-05-19 20:15:33+00:00
Summary: Grab Python using miniconda
Affected #: 1 file
diff -r 91e941b6a3d420630d83eca8e5a5342701bb80f8 -r e6627bf8a52de38b23ef3278605de3c2fd19f28a appveyor.yml
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -30,10 +30,10 @@
- "python --version"
# Install specified version of numpy and dependencies
- - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools Cython sympy h5py matplotlib"
+ - "conda install -q --yes numpy=%NUMPY_VERSION% nose setuptools ipython Cython sympy h5py matplotlib"
- "python setup.py develop"
-# Not a .NET project, we build SunPy in the install step instead
+# Not a .NET project
build: false
test_script:
Repository URL: https://bitbucket.org/yt_analysis/yt/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
More information about the yt-svn
mailing list