[yt-svn] commit/yt: 3 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Thu Apr 27 13:26:06 PDT 2017
3 new commits in yt:
https://bitbucket.org/yt_analysis/yt/commits/150af48c4252/
Changeset: 150af48c4252
Branch: stable
User: ngoldbaum
Date: 2017-04-27 14:54:03+00:00
Summary: Backporting PR 2588
Affected #: 2 files
diff -r ad3124510d3e12361134e06da4112bc9f828ffc7 -r 150af48c425212cac9ce70ebe0900245d48368d3 yt/funcs.py
--- a/yt/funcs.py
+++ b/yt/funcs.py
@@ -511,7 +511,65 @@
class YTEmptyClass(object):
pass
-def update_hg(path, skip_rebuild = False):
+def update_hg_or_git(path):
+ if os.path.exists(os.sep.join([path, '.hg'])):
+ update_hg(path)
+ elif os.path.exists(os.sep.join([path, '.git'])):
+ update_git(path)
+
+def update_git(path):
+ try:
+ import git
+ except ImportError:
+ print("Updating and precise version information requires ")
+ print("gitpython to be installed.")
+ print("Try: pip install gitpython")
+ return -1
+ with open(os.path.join(path, "yt_updater.log"), "a") as f:
+ with git.Repo(path) as repo:
+ if repo.is_dirty(untracked_files=True):
+ print("Changes have been made to the yt source code so I won't ")
+ print("update the code. You will have to do this yourself.")
+ print("Here's a set of sample commands:")
+ print("")
+ print(" $ cd %s" % (path))
+ print(" $ git stash")
+ print(" $ git checkout master")
+ print(" $ git pull")
+ print(" $ git stash pop")
+ print(" $ %s setup.py develop" % (sys.executable))
+ print("")
+ return 1
+ if repo.active_branch.name != 'master':
+ print("yt repository is not tracking the master branch so I won't ")
+ print("update the code. You will have to do this yourself.")
+ print("Here's a set of sample commands:")
+ print("")
+ print(" $ cd %s" % (path))
+ print(" $ git checkout master")
+ print(" $ git pull")
+ print(" $ %s setup.py develop" % (sys.executable))
+ print("")
+ return 1
+ print("Updating the repository")
+ f.write("Updating the repository\n\n")
+ old_version = repo.git.rev_parse('HEAD', short=12)
+ try:
+ remote = repo.remotes.yt_upstream
+ except AttributeError:
+ remote = repo.create_remote(
+ 'yt_upstream', url='https://github.com/yt-project/yt')
+ remote.fetch()
+ master = repo.heads.master
+ master.set_tracking_branch(remote.refs.master)
+ master.checkout()
+ remote.pull()
+ new_version = repo.git.rev_parse('HEAD', short=12)
+ f.write('Updated from %s to %s\n\n' % (old_version, new_version))
+ rebuild_modules(path, f)
+ print('Updated successfully')
+
+def update_hg(path):
try:
import hglib
except ImportError:
@@ -520,33 +578,65 @@
return -1
f = open(os.path.join(path, "yt_updater.log"), "a")
with hglib.open(path) as repo:
- repo.pull()
+ repo.pull(b'https://bitbucket.org/yt_analysis/yt')
ident = repo.identify().decode("utf-8")
if "+" in ident:
- print("Can't rebuild modules by myself.")
- print("You will have to do this yourself. Here's a sample commands:")
+ print("Changes have been made to the yt source code so I won't ")
+ print("update the code. You will have to do this yourself.")
+ print("Here's a set of sample commands:")
print("")
print(" $ cd %s" % (path))
- print(" $ hg up")
+ print(" $ hg up -C yt # This will delete any unsaved changes")
print(" $ %s setup.py develop" % (sys.executable))
+ print("")
return 1
print("Updating the repository")
f.write("Updating the repository\n\n")
- repo.update(check=True)
+ books = repo.bookmarks()[0]
+ books = [b[0].decode('utf8') for b in books]
+ if 'master' in books:
+ repo.update('master', check=True)
+ else:
+ repo.update('yt', check=True)
f.write("Updated from %s to %s\n\n" % (ident, repo.identify()))
- if skip_rebuild: return
- f.write("Rebuilding modules\n\n")
- p = subprocess.Popen([sys.executable, "setup.py", "build_ext", "-i"],
- cwd=path, stdout = subprocess.PIPE,
- stderr = subprocess.STDOUT)
- stdout, stderr = p.communicate()
- f.write(stdout.decode('utf-8'))
- f.write("\n\n")
- if p.returncode:
- print("BROKEN: See %s" % (os.path.join(path, "yt_updater.log")))
- sys.exit(1)
- f.write("Successful!\n")
- print("Updated successfully.")
+ rebuild_modules(path, f)
+ print("Updated successfully.")
+
+def rebuild_modules(path, f):
+ f.write("Rebuilding modules\n\n")
+ p = subprocess.Popen([sys.executable, "setup.py", "build_ext", "-i"],
+ cwd=path, stdout = subprocess.PIPE,
+ stderr = subprocess.STDOUT)
+ stdout, stderr = p.communicate()
+ f.write(stdout.decode('utf-8'))
+ f.write("\n\n")
+ if p.returncode:
+ print("BROKEN: See %s" % (os.path.join(path, "yt_updater.log")))
+ sys.exit(1)
+ f.write("Successful!\n")
+
+
+def get_hg_or_git_version(path):
+ if os.path.exists(os.sep.join([path, '.hg'])):
+ return get_hg_version(path)
+ elif os.path.exists(os.sep.join([path, '.git'])):
+ return get_git_version(path)
+ return None
+
+def get_git_version(path):
+ try:
+ import git
+ except ImportError:
+ print("Updating and precise version information requires ")
+ print("gitpython to be installed.")
+ print("Try: pip install gitpython")
+ return None
+ try:
+ with git.Repo(path) as repo:
+ return repo.git.rev_parse('HEAD', short=12)
+ except git.InvalidGitRepositoryError:
+ # path is not a git repository
+ return None
def get_hg_version(path):
try:
@@ -558,7 +648,7 @@
return None
try:
with hglib.open(path) as repo:
- return repo.identify()
+ return repo.identify().decode('utf-8')
except hglib.error.ServerError:
# path is not an hg repository
return None
diff -r ad3124510d3e12361134e06da4112bc9f828ffc7 -r 150af48c425212cac9ce70ebe0900245d48368d3 yt/utilities/command_line.py
--- a/yt/utilities/command_line.py
+++ b/yt/utilities/command_line.py
@@ -31,11 +31,11 @@
from yt.startup_tasks import parser, subparsers
from yt.funcs import \
ensure_list, \
- get_hg_version, \
+ get_hg_or_git_version, \
get_yt_version, \
mylog, \
ensure_dir_exists, \
- update_hg, \
+ update_hg_or_git, \
enable_plugins
from yt.extern.six import add_metaclass, string_types
from yt.extern.six.moves import urllib, input
@@ -78,7 +78,7 @@
def _print_failed_source_update(reinstall=False):
print()
- print("The yt package is not installed from a mercurial repository,")
+ print("The yt package is not installed from a git repository,")
print("so you must update this installation manually.")
if 'Continuum Analytics' in sys.version or 'Anaconda' in sys.version:
# see http://stackoverflow.com/a/21318941/1382869 for why we need
@@ -95,6 +95,13 @@
print("To update all of your packages, you can do:")
print()
print(" $ conda update --all")
+ else:
+ print("If you manage your python dependencies with pip, you may")
+ print("want to do:")
+ print()
+ print(" $ pip install -U yt")
+ print()
+ print("to update your yt installation.")
def _print_installation_information(path):
import yt
@@ -112,9 +119,9 @@
print()
print("---")
print("Version = %s" % yt.__version__)
- vstring = get_hg_version(path)
+ vstring = get_hg_or_git_version(path)
if vstring is not None:
- print("Changeset = %s" % vstring.strip().decode("utf-8"))
+ print("Changeset = %s" % vstring.strip())
print("---")
return vstring
@@ -185,7 +192,9 @@
_common_options = dict(
all = dict(longname="--all", dest="reinstall",
default=False, action="store_true",
- help="Reinstall the full yt stack in the current location."),
+ help=("Reinstall the full yt stack in the current location."
+ " This option has been deprecated and may not work "
+ "correctly."),),
ds = dict(short="ds", action=GetParameterFiles,
nargs="+", help="datasets to run on"),
ods = dict(action=GetParameterFiles, dest="ds",
@@ -378,7 +387,6 @@
def _get_yt_stack_date():
if "YT_DEST" not in os.environ:
- print("Could not determine when yt stack was last updated.")
return
date_file = os.path.join(os.environ["YT_DEST"], ".yt_update")
if not os.path.exists(date_file):
@@ -661,8 +669,7 @@
if vstring is not None:
print("This installation CAN be automatically updated.")
if opts.update_source:
- update_hg(path)
- print("Updated successfully.")
+ update_hg_or_git(path)
_get_yt_stack_date()
elif opts.update_source:
_print_failed_source_update()
@@ -1057,8 +1064,7 @@
if vstring is not None:
print()
print("This installation CAN be automatically updated.")
- update_hg(path, skip_rebuild=opts.reinstall)
- print("Updated successfully.")
+ update_hg_or_git(path)
_get_yt_stack_date()
if opts.reinstall:
_update_yt_stack(path)
https://bitbucket.org/yt_analysis/yt/commits/f3d79d2fdf55/
Changeset: f3d79d2fdf55
Branch: stable
User: al007
Date: 2017-04-26 13:54:03+00:00
Summary: Backporting PR 2584
Affected #: 1 file
diff -r 150af48c425212cac9ce70ebe0900245d48368d3 -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 CONTRIBUTING.rst
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -22,7 +22,7 @@
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
+ * 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
@@ -53,19 +53,18 @@
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
+documentation lives in the ``doc`` directory in the root of the yt git
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.
+more information about contributing your changes to yt on GitHub.
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
+repository <http://github.com/yt-project/website>`_ and add it there, or
email it to us and we'll add it to the `Gallery
<http://yt-project.org/gallery.html>`_.
@@ -80,20 +79,20 @@
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
+The process is pretty simple: fork on GitHub, 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.
+use GitHub.
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
+Almost everything is kept in git repositories on GitHub, and it is very easy
to fork and contribute back changes.
Please feel free to dig in and contribute changes.
@@ -210,19 +209,19 @@
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
+the community! yt is developed using git, primarily because it enables
+very easy and straightforward submission of revisions. 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
+.. note:: If you already know how to use the `git version control system
+ <https://git-scm.com/>`_ and are comfortable with handling it yourself,
+ the quickest way to contribute to yt is to `fork us on GitHub
+ <https://github.com/yt-project/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
+ <https://github.com/yt-project/yt/pulls>`_. 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
@@ -238,8 +237,8 @@
-----------
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>`_.
+`issue tracker on GitHub
+<https://github.com/yt-project/yt/issues>`_.
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
@@ -248,9 +247,8 @@
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>`_
+* Unresolved issues `marked "easy" <https://github.com/yt-project/yt/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20milestone%3Aeasy>`_.
+* `All unresolved issues <https://github.com/yt-project/yt/issues>`_
Submitting Changes
------------------
@@ -258,7 +256,7 @@
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
+discuss version control, git, or the advanced usage of GitHub in detail
here, we do provide an outline of how to submit changes and we are happy to
provide further assistance or guidance.
@@ -275,48 +273,49 @@
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
+yt is hosted on GitHub, and you can see all of the yt repositories at
+https://github.com/yt-project/. With the yt installation script you should have a
+copy of git 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.)
+GitHub 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
+main yt repository on GitHub. 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
+GitHub webpage at https://github.com/yt-project/yt/ . After logging in,
+you should see an option near the top right labeled "fork". 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:
+This forked copy exists on the GitHub repository, so in order to access
+it locally you must clone it onto your machine from the command line:
.. code-block:: bash
- $ hg clone http://bitbucket.org/<USER>/<REPOSITORY_NAME>
+ $ git clone https://github.com/<USER>/yt
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 should also run the following command, to make sure you are at
-the "yt" branch, and not other ones like "stable" (this will be important
-later when you want to submit your pull requests):
+directory.
.. code-block:: bash
- $ hg update yt
+ $ cd <REPOSITORY_NAME>
+
+Verify that you are on the master branch of yt by running:
-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
+.. code-block:: bash
+
+ $ git branch
+
+You can see any past state of the code by using the git log command.
+For example, the following command would show you the last 5 revisions
(modifications to the code) that were submitted to that repository.
.. code-block:: bash
- $ cd <REPOSITORY_NAME>
- $ hg log -l 5
+ $ git log -n 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
@@ -324,7 +323,7 @@
.. code-block:: bash
- $ hg up revision_specifier
+ $ git checkout 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
@@ -346,11 +345,11 @@
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
+``$YT_DEST/src/yt-git``. 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
+The root directory of the yt git 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:
@@ -513,68 +512,61 @@
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:
+.. _git-with-yt:
-How to Use Mercurial with yt
-----------------------------
+How to Use git with yt
+----------------------
-If you're new to Mercurial, these three resources are pretty great for learning
+If you're new to git, the following resource is 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
+* https://git-scm.com/
-The commands that are essential for using mercurial include:
+The commands that are essential for using git 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.
+* ``git <command> --help`` which provides help for any git command. For example, you
+ can learn more about the ``log`` command by doing ``git log --help``.
+* ``git add <paths>`` which stages changes to the specified paths for subsequent
+ committing (see below).
+* ``git commit`` which commits staged changes (stage using ``git add`` as above)
+ in the working directory to the repository, creating a new "revision."
+* ``git merge <branch>`` which merges the revisions from the specified branch
+ into the current branch, creating a union of their lines of development. This
+ updates the working directory.
+* ``git pull <remote><branch>`` which pulls revisions from the specified branch of the
+ specified remote repository into the current local branch. Equivalent to ``git
+ fetch <remote>`` and then ``git merge <remote>/<branch>``. This updates the
+ working directory.
+* ``git push <remote>`` which sends revisions on local branches to matching
+ branches on the specified remote. ``git push <remote><branch>`` will only
+ push changes for the specified branch.
+* ``git log`` which shows a log of all revisions on the current branch. There
+ are many options you can pass to ``git log`` to get additional
+ information. One example is ``git log --oneline --decorate --graph --all``.
-We are happy to asnswers questions about mercurial use on our IRC, slack
+We are happy to answer questions about git 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:
+Here are some general suggestions for using git 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.
+* Although not necessary, a common development work flow is to create a local
+ named branch other than ``master`` to address a feature request or bugfix. If
+ the dev work addresses a specific yt GitHub issue, you may include that issue
+ number in the branch name. For example, if you want to work on issue number X
+ regarding a cool new slice plot feature, you might name the branch:
+ ``cool_new_plot_feature_X``. When you're ready to share your work, push your
+ feature branch to your remote and create a pull request to the ``master``
+ branch of the yt-project's repository.
* 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
+ website. 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.
+* If you run into any troubles, stop by IRC (see :ref:`irc`), Slack, or the
+ mailing list.
.. _sharing-changes:
@@ -583,30 +575,34 @@
The simplest way to submit changes to yt is to do the following:
-* Build yt from the mercurial repository
+* Build yt from the git 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>`_
+* Fork the `yt repository on GitHub <https://github.com/yt-project/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
+ found in ``$YT_DEST/src/yt-git``. 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
+ git 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
+#. Fork yt on GitHub. (This step only has to be done once.) You can do
+ this at: https://github.com/yt-project/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.
+#. Create a uniquely named branch to track your work. For example: ``git
+ checkout -b my-first-pull-request``
+#. Stage your changes using ``git add <paths>``. This command take an argument
+ which is a series of filenames whose changes you want to commit. After
+ staging, execute ``git commit -m "<Commit description>. Addresses Issue
+ #X"``. Note that supplying an actual GitHub issue # in place of ``X`` will
+ cause your commit to appear in the issue tracker after pushing to your
+ remote. This can be very helpful for others who are interested in what work
+ is being done in connection to that issue.
#. 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
@@ -616,32 +612,36 @@
#. 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/
+#. Add your remote repository with a unique name identifier. It can be anything;
+ your GitHub user name is one possible choice::
- 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.
+ git remote add <YourUniqueIdentifier> https://github.com/YourUsername/yt/
+
+#. Push your changes to your remote fork using the unique identifier you just
+ created and the command::
+
+ git push <YourUniqueIdentifier> my-first-pull-request
+
+ Where you should substitute the name of the feature branch you are working on for
+ ``my-first-pull-request``.
.. note::
Note that the above approach uses HTTPS as the transfer protocol
- between your machine and BitBucket. If you prefer to use SSH - or
+ between your machine and GitHub. 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.
+ HTTPS - you may want to set up an `SSH key`_ on GitHub. Then, you use
+ the syntax ``ssh://git@github.com/YourUsername/yt``, or equivalent, in
+ place of ``https://github.com/YourUsername/yt`` in git 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
+ .. _SSH key: https://help.github.com/articles/connecting-to-github-with-ssh/
#. Issue a pull request at
- https://bitbucket.org/YourUsername/yt/pull-request/new
+ https://github.com/yt-project/yt/pull/new/master
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
@@ -650,98 +650,23 @@
#. 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:
+#. Push the changes to your fork::
- hg push https://bitbucket.org/YourUsername/yt/
+ git push <YourRemoteIdentifier><YourBranchName>
#. 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
+Working with Multiple GitHub Pull Requests
+------------------------------------------
- $ 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.
+Dealing with multiple pull requests on GitHub is straightforward. Development on
+one feature should be isolated in one named branch, say ``feature_1`` while
+development of another feature should be in another named branch, say
+``feature_2``. A push to remote ``feature_1`` will automatically update any
+active PR for which ``feature_1`` is a pointer to the ``HEAD`` commit. A push to
+``feature_1`` *will not* update any pull requests involving ``feature_2``.
.. _code-style-guide:
https://bitbucket.org/yt_analysis/yt/commits/9b35defee16d/
Changeset: 9b35defee16d
Branch: stable
User: ngoldbaum
Date: 2017-04-25 23:54:49+00:00
Summary: Backporting PR 2590
Affected #: 16 files
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/about/index.rst
--- a/doc/source/about/index.rst
+++ b/doc/source/about/index.rst
@@ -16,7 +16,7 @@
it has grown to handle any kind of data represented in a 2D or 3D volume.
yt is an Python-based open source project and is open for anyone to use or
contribute code. The entire source code and history is available to all
-at https://bitbucket.org/yt_analysis/yt .
+at http://github.com/yt-project/yt .
.. _who-is-yt:
@@ -31,7 +31,7 @@
`our members website. <http://yt-project.org/members.html>`_
For an up-to-date list of everyone who has contributed to the yt codebase,
-see the current `CREDITS <http://bitbucket.org/yt_analysis/yt/src/yt/CREDITS>`_ file.
+see the current `CREDITS <https://github.com/yt-project/yt/blob/master/CREDITS>`_ file.
For a more detailed breakup of contributions made by individual users, see out
`Open HUB page <https://www.openhub.net/p/yt_amr/contributors?query=&sort=commits>`_.
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/analyzing/analysis_modules/halo_mass_function.rst
--- a/doc/source/analyzing/analysis_modules/halo_mass_function.rst
+++ b/doc/source/analyzing/analysis_modules/halo_mass_function.rst
@@ -1,5 +1,12 @@
.. _halo_mass_function:
+.. note::
+
+ This module has been deprecated as it no longer functions correctly and is
+ unmaintained. The code has been moved to the `yt attic
+ <https://github.com/yt-project/yt_attic>`__. If you'd like to take it
+ over, please do!
+
Halo Mass Function
==================
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/analyzing/analysis_modules/star_analysis.rst
--- a/doc/source/analyzing/analysis_modules/star_analysis.rst
+++ b/doc/source/analyzing/analysis_modules/star_analysis.rst
@@ -1,5 +1,11 @@
.. _star_analysis:
+.. note::
+
+ This module has been deprecated as it is unmaintained. The code has been
+ moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
+ If you'd like to take it over, please do!
+
Star Particle Analysis
======================
.. sectionauthor:: Stephen Skory <sskory at physics.ucsd.edu>
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/analyzing/analysis_modules/sunrise_export.rst
--- a/doc/source/analyzing/analysis_modules/sunrise_export.rst
+++ b/doc/source/analyzing/analysis_modules/sunrise_export.rst
@@ -1,5 +1,11 @@
.. _sunrise_export:
+.. note::
+
+ This module has been deprecated as it is unmaintained. The code has been
+ moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
+ If you'd like to take it over, please do!
+
Exporting to Sunrise
====================
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/analyzing/analysis_modules/two_point_functions.rst
--- a/doc/source/analyzing/analysis_modules/two_point_functions.rst
+++ b/doc/source/analyzing/analysis_modules/two_point_functions.rst
@@ -1,5 +1,11 @@
.. _two_point_functions:
+.. note::
+
+ This module has been deprecated as it is unmaintained. The code has been
+ moved to the `yt attic <https://github.com/yt-project/yt_attic>`__.
+ If you'd like to take it over, please do!
+
Two Point Functions
===================
.. sectionauthor:: Stephen Skory <sskory at physics.ucsd.edu>
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/analyzing/units/index.rst
--- a/doc/source/analyzing/units/index.rst
+++ b/doc/source/analyzing/units/index.rst
@@ -12,8 +12,8 @@
and execute the documentation interactively, you need to download the repository
and start the IPython notebook.
-You will then need to navigate to :code:`$YT_HG/doc/source/units` (where $YT_HG
-is the location of a clone of the yt mercurial repository), and then start an
+You will then need to navigate to :code:`$YT_GIT/doc/source/units` (where $YT_GIT
+is the location of a clone of the yt git repository), and then start an
IPython notebook server:
.. code:: bash
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/developing/building_the_docs.rst
--- a/doc/source/developing/building_the_docs.rst
+++ b/doc/source/developing/building_the_docs.rst
@@ -19,9 +19,9 @@
include a recipe in the cookbook section, or it could simply be adding a note
in the relevant docs text somewhere.
-The documentation exists in the main mercurial code repository for yt in the
-``doc`` directory (i.e. ``$YT_HG/doc/source`` where ``$YT_HG`` is the path of
-the yt mercurial repository). It is organized hierarchically into the main
+The documentation exists in the main code repository for yt in the
+``doc`` directory (i.e. ``$YT_GIT/doc/source`` where ``$YT_GIT`` is the path of
+the yt git repository). It is organized hierarchically into the main
categories of:
* Visualizing
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/developing/extensions.rst
--- a/doc/source/developing/extensions.rst
+++ b/doc/source/developing/extensions.rst
@@ -40,10 +40,10 @@
A template for starting an extension module (or converting an existing set of
code to an extension module) can be found at
-https://bitbucket.org/yt_analysis/yt_extension_template .
+https://github.com/yt-project/yt_extension_template .
To get started, download a zipfile of the template (
-https://bitbucket.org/yt_analysis/yt_extension_template/get/tip.zip ) and
+https://github.com/yt-project/yt_extension_template/archive/master.zip ) and
follow the directions in ``README.md`` to modify the metadata.
Distributing Extensions
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/developing/releasing.rst
--- a/doc/source/developing/releasing.rst
+++ b/doc/source/developing/releasing.rst
@@ -12,9 +12,8 @@
once a month. These releases should contain only fixes for bugs discovered in
earlier releases and should not contain new features or API changes. Bugfix
releases should increment the ``PATCH`` version number. Bugfix releases should
- *not* be generated by merging from the ``yt`` branch, instead bugfix pull
- requests should be manually backported using the PR backport script, described
- below. Version ``3.2.2`` is a bugfix release.
+ *not* be generated by merging from the ``master`` branch, instead bugfix pull
+ requests should be manually backported. Version ``3.2.2`` is a bugfix release.
* Minor releases
@@ -25,7 +24,7 @@
backwards-incompatible changes and should not change APIs. If an API change
is deemed to be necessary, the old API should continue to function but might
trigger deprecation warnings. Minor releases should happen by merging the
- ``yt`` branch into the ``stable`` branch. Minor releases should increment the
+ ``master`` branch into the ``stable`` branch. Minor releases should increment the
``MINOR`` version number and reset the ``PATCH`` version number to zero.
Version ``3.3.0`` is a minor release.
@@ -36,7 +35,7 @@
include arbitrary changes to the library. Major version releases should only
happen after extensive discussion and vetting among the developer and user
community. Like minor releases, a major release should happen by merging the
- ``yt`` branch into the ``stable`` branch. Major releases should increment the
+ ``master`` branch into the ``stable`` branch. Major releases should increment the
``MAJOR`` version number and reset the ``MINOR`` and ``PATCH`` version numbers
to zero. If it ever happens, version ``4.0.0`` will be a major release.
@@ -49,99 +48,25 @@
As described above, bugfix releases are regularly scheduled updates for minor
releases to ensure fixes for bugs make their way out to users in a timely
manner. Since bugfix releases should not include new features, we do not issue
-bugfix releases by simply merging from the development ``yt`` branch into the
-``stable`` branch. Instead, we make use of the ``pr_backport.py`` script to
-manually cherry-pick bugfixes from the from ``yt`` branch onto the ``stable``
-branch.
-
-The backport script issues interactive prompts to backport individual pull
-requests to the ``stable`` branch in a temporary clone of the main yt mercurial
-repository on bitbucket. The script is written this way to to avoid editing
-history in a clone of the repository that a developer uses for day-to-day work
-and to avoid mixing work-in-progress changes with changes that have made their
-way to the "canonical" yt repository on bitbucket.
-
-Rather than automatically manipulating the temporary repository by scripting
-mercurial commands using ``python-hglib``, the script must be "operated" by a
-human who is ready to think carefully about what the script is telling them
-to do. Most operations will merely require copy/pasting a suggested mercurial
-command. However, some changes will require manual backporting.
-
-To run the backport script, first open two terminal windows. The first window
-will be used to run the backport script. The second terminal will be used to
-manipulate a temporary clone of the yt mercurial repository. In the first
-window, navigate to the ``scripts`` directory at the root of the yt repository
-and run the backport script,
-
-.. code-block:: bash
-
- $ cd $YT_HG/scripts
- $ python pr_backport.py
-
-You will then need to wait for about a minute (depending on the speed of your
-internet connection and bitbucket's servers) while the script makes a clone of
-the main yt repository and then gathers information about pull requests that
-have been merged since the last tagged release. Once this step finishes, you
-will be prompted to navigate to the temporary folder in a new separate terminal
-session. Do so, and then hit the enter key in the original terminal session.
-
-For each pull request in the set of pull requests that were merged since the
-last tagged release that were pointed at the "main" line of development
-(e.g. not the ``experimental`` bookmark), you will be prompted by the script
-with the PR number, title, description, and a suggested mercurial
-command to use to backport the pull request. If the pull request consists of a
-single changeset, you will be prompted to use ``hg graft``. If it contains more
-than one changeset, you will be prompted to use ``hg rebase``. Note that
-``rebase`` is an optional extension for mercurial that is not turned on by
-default. To enable it, add a section like the following in your ``.hgrc`` file:
-
-.. code-block:: none
-
- [extensions]
- rebase=
-
-Since ``rebase`` is bundled with core mercurial, you do not need to specify a
-path to the rebase extension, just say ``rebase=`` and mercurial will find the
-version of ``rebase`` bundled with mercurial. Note also that mercurial does not
-automatically update to the tip of the rebased head after executing ``hg
-rebase`` so you will need to manually issue ``hg update stable`` to move your
-working directory to the new head of the stable branch. The backport script
-should prompt you with a suggestion to update as well.
+bugfix releases by simply merging from the development ``master`` branch into
+the ``stable`` branch. Instead, we manually cherry-pick bugfixes from the from
+``master`` branch onto the ``stable`` branch.
If the pull request contains merge commits, you must take care to *not* backport
-commits that merge with the main line of development on the ``yt`` branch. Doing
+commits that merge with the main line of development on the ``master`` branch. Doing
so may bring unrelated changes, including new features, into a bugfix
-release. If the pull request you'd like to backport contains merge commits, the
-backport script should warn you to be extra careful.
+release.
-Once you've finished backporting, the script will let you know that you are done
-and warn you to push your work. The temporary repository you have been working
-with will be deleted as soon as the script exits, so take care to push your work
-on the ``stable`` branch to your fork on bitbucket. Once you've pushed to your
-fork, you will be able to issue a pull request containing the backported fixes
-just like any other yt pull request.
+Once you've finished backporting push your work to Github. Once you've pushed to
+your fork, you will be able to issue a pull request containing the backported
+fixes just like any other yt pull request.
Doing a Minor or Major Release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is much simpler than a bugfix release. All that needs to happen is the
-``yt`` branch must get merged into the ``stable`` branch, and any conflicts that
-happen must be resolved, almost certainly in favor of the yt branch. This can
-happen either using a merge tool like ``vimdiff`` and ``kdiff3`` or by telling
-mercurial to write merge markers. If you prefer merge markers, the following
-configuration options should be turned on in your ``hgrc`` to get more detail
-during the merge:
-
-.. code-block:: none
-
- [ui]
- merge = internal:merge3
- mergemarkers = detailed
-
-The first option tells mercurial to write merge markers that show the state of
-the conflicted region of the code on both sides of the merge as well as the
-"base" most recent common ancestor changeset. The second option tells mercurial
-to add extra information about the code near the merge markers.
+``master`` branch must get merged into the ``stable`` branch, and any conflicts
+that happen must be resolved.
Incrementing Version Numbers and Tagging a Release
@@ -174,35 +99,42 @@
.. code-block:: bash
- hg tag <tag-name>
+ git tag <tag-name>
Where ``<tag-name>`` follows the project's naming scheme for tags
-(e.g. ``yt-3.2.1``). Commit the tag, and you should be ready to upload the
-release to pypi.
+(e.g. ``yt-3.2.1``). Once you are done, you will need to push the
+tag to github::
+
+ git push origin --tags
-If you are doing a minor or major version number release, you will also need to
-update back to the development branch and update the development version numbers
-in the same files.
+This assumes that you have configured the remote ``origin`` to point at the main
+yt git repository. If you are doing a minor or major version number release, you
+will also need to update back to the development branch and update the
+development version numbers in the same files.
Uploading to PyPI
~~~~~~~~~~~~~~~~~
To actually upload the release to the Python Package Index, you just need to
-issue the following command:
+issue the following commands:
.. code-block:: bash
- python setup.py sdist upload -r https://pypi.python.org/pypi
+ python setup.py sdist
+ twine upload dist/*
You will be prompted for your PyPI credentials and then the package should
upload. Note that for this to complete successfully, you will need an account on
PyPI and that account will need to be registered as an "owner" of the yt
-package. Right now there are three owners: Matt Turk, Britton Smith, and Nathan
-Goldbaum.
+package. Right now there are five owners: Matt Turk, Britton Smith, Nathan
+Goldbaum, John ZuHone, and Kacper Kowalik. In addition, you should attempt to
+upload the yt package along with compiled binary wheel packages for various
+platforms that we support. You should contact John ZuHone about uploading
+binary wheels to PyPI for Windows and OS X users, Kacper Kowalik for Linux
+wheels, and contact Nathan Goldbaum about getting the Anaconda packages updated.
+
After the release is uploaded to PyPI, you should send out an announcement
e-mail to the yt mailing lists as well as other possibly interested mailing
-lists for all but bugfix releases. In addition, you should contact John ZuHone
-about uploading binary wheels to PyPI for Windows and OS X users and contact
-Nathan Goldbaum about getting the Anaconda packages updated.
+lists for all but bugfix releases.
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/developing/testing.rst
--- a/doc/source/developing/testing.rst
+++ b/doc/source/developing/testing.rst
@@ -50,19 +50,19 @@
If you are developing new functionality, it is sometimes more convenient to use
the Nose command line interface, ``nosetests``. You can run the unit tests
-using ``nose`` by navigating to the base directory of the yt mercurial
+using ``nose`` by navigating to the base directory of the yt git
repository and invoking ``nosetests``:
.. code-block:: bash
- $ cd $YT_HG
+ $ cd $YT_GIT
$ nosetests
-where ``$YT_HG`` is the path to the root of the yt mercurial repository.
+where ``$YT_GIT`` is the path to the root of the yt git repository.
If you want to specify a specific unit test to run (and not run the entire
suite), you can do so by specifying the path of the test relative to the
-``$YT_HG/yt`` directory -- note that you strip off one yt more than you
+``$YT_GIT/yt`` directory -- note that you strip off one yt more than you
normally would! For example, if you want to run the plot_window tests, you'd
run:
@@ -308,7 +308,7 @@
.. code-block:: bash
- $ cd $YT_HG
+ $ cd $YT_GIT
$ nosetests --with-answer-testing --local --local-dir $HOME/Documents/test --answer-store --answer-name=local-tipsy yt.frontends.tipsy
This command will create a set of local answers from the tipsy frontend tests
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/faq/index.rst
--- a/doc/source/faq/index.rst
+++ b/doc/source/faq/index.rst
@@ -75,10 +75,10 @@
.. code-block:: bash
- cd $YT_HG
+ cd $YT_GIT
python setup.py develop
-where ``$YT_HG`` is the path to the yt mercurial repository.
+where ``$YT_GIT`` is the path to the yt git repository.
This error tends to occur when there are changes in the underlying cython
files that need to be rebuilt, like after a major code update or in switching
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/help/index.rst
--- a/doc/source/help/index.rst
+++ b/doc/source/help/index.rst
@@ -58,8 +58,8 @@
loading yt either from the command line or from within python also fails, it
may simply mean you need to rebuild the yt source (some of the c-code in yt
needs to be rebuilt after major changes). You can do this by navigating to
-the root of the yt mercurial repository. If you installed with the all-in-one
-installer script, this is the ``yt-<machine>/src/yt-hg`` directory. Then
+the root of the yt git repository. If you installed with the all-in-one
+installer script, this is the ``yt-<machine>/src/yt-git`` directory. Then
execute these commands:
.. code-block:: bash
@@ -112,13 +112,14 @@
We've done our best to make the source clean, and it is easily searchable from
your computer.
-If you have not done so already (see :ref:`source-installation`), clone a copy of the yt mercurial repository and make it the 'active' installation by doing
+If you have not done so already (see :ref:`source-installation`), clone a copy
+of the yt git repository and make it the 'active' installation by doing
.. code-block:: bash
python setup.py develop
-in the root directory of the yt mercurial repository.
+in the root directory of the yt git repository.
.. note::
@@ -126,7 +127,7 @@
script. Building yt from source will not work if you do not have a C compiler
installed.
-Once inside the yt mercurial repository, you can then search for the class,
+Once inside the yt git repository, you can then search for the class,
function, or keyword which is giving you problems with ``grep -r *``, which will
recursively search throughout the code base. (For a much faster and cleaner
experience, we recommend ``grin`` instead of ``grep -r *``. To install ``grin``
@@ -137,7 +138,7 @@
.. code-block:: bash
- $ cd $YT-HG/yt
+ $ cd $YT_GIT/yt
$ grep -r SlicePlot * (or $ grin SlicePlot)
This will print a number of locations in the yt source tree where ``SlicePlot``
@@ -209,13 +210,12 @@
-------------------
If you have gone through all of the above steps, and you're still encountering
-problems, then you have found a bug.
-To submit a bug report, you can either directly create one through the
-BitBucket `web interface <http://bitbucket.org/yt_analysis/yt/issues/new>`_,
-or you can use the command line ``yt bugreport`` to interactively create one.
-Alternatively, email the ``yt-users`` mailing list and we will construct a new
-ticket in your stead. Remember to include the information
-about your problem you identified in :ref:`this step <isolate_and_document>`.
+problems, then you have found a bug. To submit a bug report, you can either
+directly create one through the GitHub `web interface
+<http://github.org/yt-project/yt/issues/new>`_. Alternatively, email the
+``yt-users`` mailing list and we will construct a new ticket in your stead.
+Remember to include the information about your problem you identified in
+:ref:`this step <isolate_and_document>`.
Special Issues
--------------
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/installing.rst
--- a/doc/source/installing.rst
+++ b/doc/source/installing.rst
@@ -48,24 +48,23 @@
.. _branches-of-yt:
-Branches of yt: ``yt``, ``stable``, and ``yt-2.x``
-++++++++++++++++++++++++++++++++++++++++++++++++++
+Branches of yt: ``master``, ``stable``, and ``yt-2.x``
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Before you install yt, you must decide which branch (i.e. version) of the code
you prefer to use:
-* ``yt`` -- The most up-to-date *development* version with the most current
- features but sometimes unstable (the development version of the next ``yt-3.x``
- release).
+* ``master`` -- The most up-to-date *development* version with the most current
+ features but sometimes unstable (the development version of the next release).
* ``stable`` -- The latest stable release of ``yt-3.x``.
* ``yt-2.x`` -- The last stable release of ``yt-2.x``.
If this is your first time using the code, we recommend using ``stable``, unless
you specifically need some piece of brand-new functionality only available in
-``yt`` or need to run an old script developed for ``yt-2.x``. There were major
+``master`` or need to run an old script developed for ``yt-2.x``. There were major
API and functionality changes made in yt for version 3.0. For a detailed
description of the changes between versions 2.x (e.g. branch ``yt-2.x``) and 3.x
-(e.g. branches ``yt`` and ``stable``) see :ref:`yt3differences`. Lastly, don't
+(e.g. branches ``master`` and ``stable``) see :ref:`yt3differences`. Lastly, don't
feel like you're locked into one branch when you install yt, because you can
easily change the active branch by following the instructions in
:ref:`switching-between-yt-versions`.
@@ -78,7 +77,7 @@
Because installation of all of the interlocking parts necessary to install yt
itself can be time-consuming, yt provides an all-in-one installation script
which downloads and builds a fully-isolated installation of Python that includes
-NumPy, Matplotlib, H5py, Mercurial, and yt.
+NumPy, Matplotlib, H5py, git, and yt.
The install script supports UNIX-like systems, including Linux, OS X, and most
supercomputer and cluster environments. It is particularly suited for deployment
@@ -99,13 +98,13 @@
.. code-block:: bash
- $ wget http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+ $ wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
If you do not have ``wget``, the following should also work:
.. code-block:: bash
- $ curl -OL http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+ $ curl -OL https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
By default, the bash install script will create a python environment based on
the `miniconda python distrubtion <http://conda.pydata.org/miniconda.html>`_,
@@ -119,7 +118,7 @@
If you would like to build yt from source, you will need to edit the install
script and set ``INST_YT_SOURCE=1`` near the top. This will clone a copy of the
-yt mercurial repository and build yt form source. The default is
+yt git repository and build yt form source. The default is
``INST_YT_SOURCE=0``, which installs yt from a binary conda package.
The install script can also build python and all yt dependencies from source. To
@@ -309,28 +308,15 @@
.. code-block:: bash
- $ conda install cython mercurial sympy ipython matplotlib
+ $ conda install -c conda-forge cython git sympy ipython matplotlib netCDF4
In addition, you will need a C compiler installed.
-.. note::
-
- If you are using a python3 environment, ``conda`` will not be able to install
- *mercurial*, which works only with python2. You can circumvent this issue by
- creating a dedicated python2 environment and symlinking *hg* in your current
- environment:
-
- .. code-block:: bash
-
- $ export CONDA_DIR=$(python -c 'import sys; print(sys.executable.split("/bin/python")[0])')
- $ conda create -y -n py27 python=2.7 mercurial
- $ ln -s ${CONDA_DIR}/envs/py27/bin/hg ${CONDA_DIR}/bin
-
Clone the yt repository with:
.. code-block:: bash
- $ hg clone https://bitbucket.org/yt_analysis/yt
+ $ git clone https://github.com/yt-project/yt
Once inside the yt directory, update to the appropriate branch and
run ``setup.py develop``. For example, the following commands will allow you
@@ -338,8 +324,7 @@
.. code-block:: bash
- $ hg pull
- $ hg update yt
+ $ git checkout master
$ python setup.py develop
This will make sure you are running a version of yt corresponding to the
@@ -358,7 +343,7 @@
.. code-block:: bash
- $ hg clone https://bitbucket.org/MatthewTurk/rockstar
+ $ git clone https://github.com/yt-project/rockstar
$ cd rockstar
$ make lib
@@ -369,17 +354,17 @@
$ cp librockstar.so /path/to/anaconda/lib
Finally, you will need to recompile yt to enable the rockstar interface. Clone a
-copy of the yt mercurial repository (see :ref:`conda-source-build`), or navigate
+copy of the yt git repository (see :ref:`conda-source-build`), or navigate
to a clone that you have already made, and do the following:
.. code-block:: bash
- $ cd /path/to/yt-hg
+ $ cd /path/to/yt-git
$ ./clean.sh
$ echo /path/to/rockstar > rockstar.cfg
$ python setup.py develop
-Here ``/path/to/yt-hg`` is the path to your clone of the yt mercurial repository
+Here ``/path/to/yt-git`` is the path to your clone of the yt git repository
and ``/path/to/rockstar`` is the path to your clone of Matt Turk's fork of
rockstar.
@@ -406,8 +391,8 @@
^^^^^^^^^^^^^^^^^^^^^^^^
Installation on 64-bit Microsoft Windows platforms is supported using Anaconda
-(see :ref:`anaconda-installation`). Also see :ref:`windows-developing` for
-details on how to build yt from source in Windows.
+(see :ref:`anaconda-installation`) and via ``pip``. Also see
+:ref:`windows-developing` for details on how to build yt from source in Windows.
.. _source-installation:
@@ -423,7 +408,7 @@
installed on your system. Right now, the dependencies to build yt from
source include:
-- ``mercurial``
+- ``git``
- A C compiler such as ``gcc`` or ``clang``
- ``Python 2.7``, ``Python 3.4``, or ``Python 3.5``
@@ -445,16 +430,15 @@
$ pip install yt
-The source code for yt may be found at the Bitbucket project site and can also
-be utilized for installation. If you prefer to install the development version
-of yt instead of the latest stable release, you will need ``mercurial`` to clone
-the official repo:
+The source code for yt may be found on GitHub. If you prefer to install the
+development version of yt instead of the latest stable release, you will need
+``git`` to clone the official repo:
.. code-block:: bash
- $ hg clone https://bitbucket.org/yt_analysis/yt
+ $ git clone https://github.com/yt-project/yt
$ cd yt
- $ hg update yt
+ $ git checkout master
$ python setup.py install --user --prefix=
.. note::
@@ -479,14 +463,14 @@
If you choose this installation method, you do not need to run any activation
script since this will install yt into your global python environment.
-If you will be modifying yt, you can also make the clone of the yt mercurial
+If you will be modifying yt, you can also make the clone of the yt git
repository the "active" installed copy:
.. code-block:: bash
- $ hg clone https://bitbucket.org/yt_analysis/yt
+ $ git clone https://github.com/yt-project/yt
$ cd yt
- $ hg update yt
+ $ git checkout master
$ python setup.py develop --user --prefix=
As above, you can leave off ``--user --prefix=`` if you want to install yt into the default
@@ -513,13 +497,13 @@
or via your preferred method.
-Keeping yt Updated via Mercurial
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Keeping yt Updated via Git
+^^^^^^^^^^^^^^^^^^^^^^^^^^
If you want to maintain your yt installation via updates straight from the
-Bitbucket repository or if you want to do some development on your own, we
+GitHub repository or if you want to do some development on your own, we
suggest you check out some of the :ref:`development docs <contributing-code>`,
-especially the sections on :ref:`Mercurial <mercurial-with-yt>` and
+especially the sections on :ref:`Git <git-with-yt>` and
:ref:`building yt from source <building-yt>`.
You can also make use of the following command to keep yt up to date from the
@@ -529,8 +513,8 @@
$ yt update
-This will detect that you have installed yt from the mercurial repository, pull
-any changes from Bitbucket, and then recompile yt if necessary.
+This will detect that you have installed yt from the git repository, pull any
+changes from GitHub, and then recompile yt if necessary.
.. _testing-installation:
@@ -556,7 +540,7 @@
.. _switching-between-yt-versions:
-Switching versions of yt: ``yt-2.x``, ``stable``, and ``yt`` branches
+Switching versions of yt: ``yt-2.x``, ``stable``, and ``master`` branches
---------------------------------------------------------------------
Here we explain how to switch between different development branches of yt.
@@ -594,10 +578,10 @@
---
Version = 3.3-dev
- Changeset = d8eec89b2c86 (yt) tip
+ Changeset = d8eec89b2c86
---
-i.e. it refers to a specific changeset in the yt mercurial repository, then
+i.e. it refers to a specific changeset in the yt git repository, then
you installed using ``INST_YT_SOURCE=1``.
Conda-based installs (``INST_YT_SOURCE=0``)
@@ -608,15 +592,15 @@
Source-based installs (``INST_YT_SOURCE=1``)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-You already have the mercurial repository, so you simply need to switch
-which version you're using. Navigate to the root of the yt mercurial
-repository, update to the desired version, and rebuild the source (some of the
+You already have the git repository, so you simply need to switch
+which version you're using. Navigate to the root of the yt git
+repository, check out the desired version, and rebuild the source (some of the
C code requires a compilation step for big changes like this):
.. code-block:: bash
- $ cd yt-<machine>/src/yt-hg
- $ hg update <desired-version>
+ $ cd yt-<machine>/src/yt-git
+ $ git checkout <desired version>
$ python setup.py develop
Valid versions to jump to are described in :ref:`branches-of-yt`.
@@ -628,22 +612,21 @@
++++++++++++++++++++++++++++++++++++++++++++++++++
If you have installed python via ``pip``, remove
-any extant installations of yt on your system and clone the source mercurial
+any extant installations of yt on your system and clone the git
repository of yt as described in :ref:`source-installation`.
.. code-block:: bash
$ pip uninstall yt
- $ hg clone https://bitbucket.org/yt_analysis/yt
+ $ git clone https://github.com/yt-project/yt
-Now, to switch between versions, you need to navigate to the root of
-the mercurial yt repository. Use mercurial to
-update to the appropriate version and recompile.
+Now, to switch between versions, you need to navigate to the root of the git yt
+repository. Use git to update to the appropriate version and recompile.
.. code-block:: bash
$ cd yt
- $ hg update <desired-version>
+ $ git checkout <desired-version>
$ python setup.py install --user --prefix=
Valid versions to jump to are described in :ref:`branches-of-yt`).
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/quickstart/index.rst
--- a/doc/source/quickstart/index.rst
+++ b/doc/source/quickstart/index.rst
@@ -25,11 +25,11 @@
If you're running the tutorial from your own system and you do not already have
the yt repository, the easiest way to get the repository is to clone it using
-mercurial:
+git:
.. code-block:: bash
- hg clone https://bitbucket.org/yt_analysis/yt
+ git clone https://github.com/yt-project/yt
Now start the IPython notebook from within the repository (we presume you have
yt installed):
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/reference/command-line.rst
--- a/doc/source/reference/command-line.rst
+++ b/doc/source/reference/command-line.rst
@@ -102,7 +102,7 @@
First, we'll discuss plotting from the command line, then we will give a brief
summary of the functionality provided by each command line subcommand. This
example uses the :code:`DD0010/moving7_0010` dataset distributed in the yt
-mercurial repository.
+git repository.
First let's see what our options are for plotting:
diff -r f3d79d2fdf553d1657bf664b8d25278a7f78db69 -r 9b35defee16d897a61d0becfc9ad0315042fadba doc/source/visualizing/unstructured_mesh_rendering.rst
--- a/doc/source/visualizing/unstructured_mesh_rendering.rst
+++ b/doc/source/visualizing/unstructured_mesh_rendering.rst
@@ -29,7 +29,7 @@
.. code-block:: bash
- wget http://bitbucket.org/yt_analysis/yt/raw/yt/doc/install_script.sh
+ wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
and then run like so:
@@ -64,7 +64,7 @@
the unstructured mesh rendering capability. Once again, if embree is installed in a
location that is not part of your default search path, you must tell yt where to find it.
There are a number of ways to do this. One way is to again manually pass in the flags
-when running the setup script in the yt-hg directory:
+when running the setup script in the yt-git directory:
.. code-block:: bash
@@ -77,7 +77,7 @@
python setup.py develop
-as usual. Finally, if you create a file called embree.cfg in the yt-hg directory with
+as usual. Finally, if you create a file called embree.cfg in the yt-git directory with
the location of the embree installation, the setup script will find this and use it,
provided EMBREE_DIR is not set. An example embree.cfg file could like this:
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