Initial commit from package-template

.gitignore

@@ -0,0 +1,40 @@
+# Compiled files
+*.py[co]
+*.a
+*.o
+*.so
+__pycache__
+
+# Ignore .c files by default to avoid including generated code. If you want to
+# add a non-generated .c extension, use `git add -f filename.c`.
+*.c
+
+# Other generated files
+*/version.py
+*/cython_version.py
+htmlcov
+.coverage
+
+# Sphinx
+_build
+
+# Packages/installer info
+*.egg
+*.egg-info
+dist
+build
+eggs
+parts
+bin
+var
+sdist
+develop-eggs
+.installed.cfg
+distribute-*.tar.gz
+
+# Other
+.*.swp
+*~
+
+# Mac OSX
+.DS_Store

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "astropy_helpers"]
+	path = astropy_helpers
+	url = https://github.com/astropy/astropy-helpers.git

.travis.yml

@@ -0,0 +1,114 @@
+language: python
+
+python:
+    - 2.6
+    - 2.7
+    - 3.2
+    - 3.3
+    - 3.4
+    # This is just for "egg_info".  All other builds are explicitly given in the matrix
+env:
+    global:
+        # The following versions are the 'default' for tests, unless
+        # overidden underneath. They are defined here in order to save having
+        # to repeat them for all configurations.
+        - NUMPY_VERSION=1.8
+        - ASTROPY_VERSION=stable
+        - CONDA_INSTALL='conda install -c astropy-ci-extras --yes'
+        - PIP_INSTALL='pip install'
+    matrix:
+        - SETUP_CMD='egg_info'
+
+matrix:
+    include:
+
+        # Do a coverage test in Python 2. 
+        - python: 2.7
+          env: SETUP_CMD='test --coverage'
+
+        # Check for sphinx doc build warnings - we do this first because it
+        # may run for a long time
+        - python: 2.7
+          env: SETUP_CMD='build_sphinx -w'
+
+        # Try Astropy development version
+        - python: 2.7
+          env: ASTROPY_VERSION=development SETUP_CMD='test'
+        - python: 3.3
+          env: ASTROPY_VERSION=development SETUP_CMD='test'
+
+        # Try all python versions with the latest numpy
+        - python: 2.6
+          env: SETUP_CMD='test'
+        - python: 2.7
+          env: SETUP_CMD='test'
+        - python: 3.2
+          env: SETUP_CMD='test'
+        - python: 3.3
+          env: SETUP_CMD='test'
+        - python: 3.4
+          env: SETUP_CMD='test'
+
+        # Try older numpy versions
+        - python: 3.2
+          env: NUMPY_VERSION=1.6 SETUP_CMD='test'
+        - python: 2.7
+          env: NUMPY_VERSION=1.7 SETUP_CMD='test'
+        - python: 2.7
+          env: NUMPY_VERSION=1.6 SETUP_CMD='test'
+        - python: 2.7
+          env: NUMPY_VERSION=1.5 SETUP_CMD='test'
+
+before_install:
+
+    # Use utf8 encoding. Should be default, but this is insurance against
+    # future changes
+    - export PYTHONIOENCODING=UTF8
+    - wget http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh -O miniconda.sh
+    - chmod +x miniconda.sh
+    - ./miniconda.sh -b
+    - export PATH=/home/travis/miniconda/bin:$PATH
+    - conda update --yes conda
+
+    # DOCUMENTATION DEPENDENCIES
+    - if [[ $SETUP_CMD == build_sphinx* ]]; then sudo apt-get install graphviz texlive-latex-extra dvipng; fi
+
+install:
+
+    # CONDA
+    - conda create --yes -n test -c astropy-ci-extras python=$TRAVIS_PYTHON_VERSION
+    - source activate test
+
+    # CORE DEPENDENCIES
+    - if [[ $SETUP_CMD != egg_info ]]; then $CONDA_INSTALL numpy=$NUMPY_VERSION pytest pip Cython; fi
+    - if [[ $SETUP_CMD != egg_info ]]; then $PIP_INSTALL pytest-xdist; fi
+
+    # ASTROPY
+    - if [[ $SETUP_CMD != egg_info ]] && [[ $ASTROPY_VERSION == development ]]; then $PIP_INSTALL git+http://github.com/astropy/astropy.git#egg=astropy; fi
+    - if [[ $SETUP_CMD != egg_info ]] && [[ $ASTROPY_VERSION == stable ]]; then $CONDA_INSTALL numpy=$NUMPY_VERSION astropy; fi
+
+    # OPTIONAL DEPENDENCIES
+    # Here you can add any dependencies your package may have. You can use
+    # conda for packages available through conda, or pip for any other
+    # packages. You should leave the `numpy=$NUMPY_VERSION` in the `conda`
+    # install since this ensures Numpy does not get automatically upgraded.
+    # - if [[ $SETUP_CMD != egg_info ]]; then $CONDA_INSTALL numpy=$NUMPY_VERSION ... ; fi
+    # - if [[ $SETUP_CMD != egg_info ]]; then $PIP_INSTALL ...; fi
+
+    # DOCUMENTATION DEPENDENCIES
+    # build_sphinx needs sphinx and matplotlib (for plot_directive). Note that
+    # this matplotlib will *not* work with py 3.x, but our sphinx build is
+    # currently 2.7, so that's fine
+    - if [[ $SETUP_CMD == build_sphinx* ]]; then $CONDA_INSTALL numpy=$NUMPY_VERSION Sphinx matplotlib; fi
+
+    # COVERAGE DEPENDENCIES
+    - if [[ $SETUP_CMD == 'test --coverage' ]]; then $PIP_INSTALL coverage coveralls; fi
+
+script:
+   - python setup.py $SETUP_CMD
+
+after_success:
+    # If coveralls.io is set up for this package, uncomment the line
+    # below and replace "packagename" with the name of your package.
+    # The coveragerc file may be customized as needed for your package.
+    # - if [[ $SETUP_CMD == 'test --coverage' ]]; then coveralls --rcfile='packagename/tests/coveragerc'; fi

MANIFEST.in

@@ -0,0 +1,18 @@
+include README.rst
+
+include ez_setup.py
+include ah_bootstrap.py
+include setup.cfg
+
+recursive-include docs *
+recursive-include licenses *
+recursive-include cextern *
+recursive-include scripts *
+
+exclude *.pyc *.o
+prune docs/_build
+prune build
+
+recursive-include astropy_helpers *
+exclude astropy_helpers/.git
+exclude astropy_helpers/.gitignore

README.md

@@ -0,0 +1,4 @@
+imageutils
+==========
+
+Image-related utilies

README.rst

@@ -0,0 +1,197 @@
+========================================
+Affiliated Package Template Instructions
+========================================
+
+If you run into any problems, don't hesitate to ask for help on the
+astropy-dev mailing list!
+
+This package provides a template for packages that are affiliated with the
+`Astropy`_ project. This package design mirrors the layout of the main
+`Astropy`_ repository, as well as reusing much of the helper code used to
+organize `Astropy`_.  The instructions below describe how to take this
+template and adjust it for your particular affiliated package.
+
+Everywhere below that the text ``yourpkg`` is shown, replace it with the name
+of your particular package.
+
+**Note**: The instructions below assume you are using git for version control,
+as is used by the Astropy repository. If this is not the case, hopefully it
+will be clear from context what to do with your particular VCS.
+
+* Make sure `Astropy`_ is installed, as the template depends in part on
+  Astropy to do its setup.
+
+* You may have already done this if you are looking at this file locally, but
+  if not, you will need to obtain a copy of the package template.  Assuming
+  you have `git`_ installed, just do::
+
+      git clone git://github.com/astropy/package-template.git yourpkg
+
+  This will download the latest version of the template from `github`_ and
+  place it in a directory named ``yourpkg``.
+
+* Go into the directory you just created, and open the ``setup.cfg``
+  file with your favorite text editor.  Edit the settings in the
+  ``metadata`` section.  These values will be used to automatically
+  replace special placeholders in the affiliated package template.
+
+  1. Change the ``package_name`` variable to whatever you decide your
+     package should be named. By tradition/very strong suggestion,
+     python package names should be all lower-case.
+  2. Change the ``description`` variable to a short (one or few
+     sentence) description of your package.
+  3. Add your name and email address by changing the ``author`` and
+     ``author_email`` variables.
+  4. If your affiliated package has a website, change ``url`` to point
+     to that site.  Otherwise, you can leave it pointing to `Astropy`_
+     or just delete it.
+  5. Exit out of your text editor
+
+* Update the main package docstring in ``packagename/__init__.py``.
+
+* Decide what license you want to use to release your source code. If
+  you don't care and/or are fine with the Astropy license, just edit
+  the file ``licenses/LICENSE.rst`` with your name (or your
+  collaboration's name) at the top as the licensees. Otherwise, make
+  sure to replace that file with whatever license you prefer, and
+  update the ``license`` variable in ``setup.cfg`` to reflect your
+  choice of license. You also may need to update the comment at the
+  top of ``packagename/__init__.py`` to reflect your choice of
+  license.
+
+* Take a moment to look over the ``packagename/example_mod.py``,
+  ``packagename/tests/test_example.py``, ``scripts/script_example``,
+  and ``packagename/example_c.pyx`` files, as well as the
+  ``packagename/example_subpkg`` directory. These are examples of a
+  pure-python module, a test script, an example command-line script, a
+  `Cython`_ module, and a sub-package, respectively. (`Cython`_ is a
+  way to compile python-like code to C to make it run faster - see the
+  project's web site for details). These are provided as examples of
+  standard way to lay these out. Once you understand these, though,
+  you'll want to delete them (and later replace with your own)::
+
+    git rm packagename/example_mod.py
+    git rm scripts/script_example
+    git rm packagename/example_c.pyx
+    git rm packagename/tests/test_example.py
+    git rm -r packagename/example_subpkg
+    git commit -m "removed examples from package template"
+
+* Optional: If you're hosting your source code on github, you can
+  enable a sphinx extension that will link documentation pages
+  directly to github's web site. To do this, set ``edit_on_github`` in
+  ``setup.cfg`` to ``True`` and set ``github_project`` to the name of
+  your project on github.
+
+* Move the main source directory to reflect the name of your package.
+  To tell your DVCS about this move, you should use it, and not ``mv``
+  directly, to make the move.  For example, with git::
+
+    git mv packagename yourpkg
+
+* Update the names of the documentation files to match your package's name.
+  First open ``docs/index.rst`` in a text editor and change the text
+  ``"packagename/index.rst"`` to e.g., ``"yourpkg/index.rst"``.  Then do::
+
+    git add docs/index.rst
+    git mv docs/packagename docs/yourpkg
+
+* Edit this file (``README.rst``) and delete all of this content, and replace it
+  with a short description of your affiliated package.
+
+* Now tell git to remember the changes you just made::
+
+    git commit -a -m "Adjusted for new project yourpkg"
+
+* (This step assumes your affiliated package is hosted as part of the astropy
+  organization on Github.  If it's instead hosted somewhere else, just adjust
+  the URL in the instructions below to match wherever your repository lives)
+  Now you will want to tell git that it should be pushing and pulling updates
+  to the repository of *your* project, rather than the package template::
+
+    git remote rename origin template
+    git remote add upstream [email protected]:astropy/yourpkg.git
+
+  Now that it is pointing to the correct master, you should push everything up
+  to your project and make sure that your local master is tied to your project
+  rather than the template.  You'll only be able to do this if your github
+  repository is empty (if not, add the ``-f`` option to the ``push``
+  command - that will overwrite whatever is there)::
+
+    git push upstream master
+    git branch master --set-upstream upstream/master
+
+* (optional) If you are adopting the standard workflow used by `Astropy`_ with
+  github, you will also want to set up a fork of the repo on your own account,
+  by going to the Github page https://github.com/astropy/yourpkg and clicking
+  the "fork" button on the upper right.  Then run the following commands::
+
+    git remote add origin [email protected]:yourgithubusername/yourpkg.git
+    git branch master --set-upstream origin/master
+
+  Now you can push, pull, and branch whatever you want in your local fork
+  without affecting the official version, but when you want to push something
+  up to the main repository, just switch to the appropriate branch and do
+  ``git push upstream master``.
+
+  Additionally, you can set things up to make it easier to pull future
+  changes to the package template to your affiliated package.  Add a remote
+  for the package template::
+
+    git remote add template [email protected]:astropy/package-template.git
+
+  Then, each time you want to pull in changes to the package template::
+
+    git fetch template
+    git fetch upstream
+
+    # Make your master match the upstream master.  This will destroy
+    # any unmerged commits on your master (which you shouldn't be doing
+    # work on anyway, according to the standard workflow).
+    git checkout master
+    git reset --hard upstream/master
+
+    # Merge any recent changes from the package-template
+    git merge template/master
+
+    # ...possibly resolve any conflicts...
+
+    # Push to upstream master
+    git push upstream master
+
+* You should register your package on https://travis-ci.org and modify the
+  ``.travis.yml`` file to make the build pass. This will continuously test
+  your package for each commit, even pull requests against your main repository
+  will be automatically tested, so that you notice when something breaks.
+  For further information see
+  `here <https://github.com/astropy/astropy/wiki/Continuous-Integration>`_
+  and for lot's of example ``.travis.yml`` build configurations see
+  `here <https://github.com/astropy/astropy/wiki/travis-ci-test-status>`_.
+  Generally you should aim to always have your `master` branch work with
+  the latest stable as well as the latest development version of astropy
+  (i.e. the astropy git master branch) and the same versions of python and
+  numpy supported by astropy. The template ``.travis.yml`` covers those
+  versions; in some circumstances you may need to limit the versions your
+  package covers.
+
+* If you register your package with coveralls.io, then you will need
+  to modify the ``coveralls --rcfile`` line in ``.travis.yml`` file to
+  replace ``packagename`` with the name of your package.
+
+* You're now ready to start doing actual work on your affiliated package.  You
+  will probably want to read over the developer guidelines of the Astropy
+  documentation, and if you are hosting your code in GitHub, you might also
+  want to read the `Github help <http://help.github.com/>`_ to ensure you know
+  how to push your code to GitHub and some recommended workflows that work for
+  the core Astropy project.
+
+* Once you have started work on the affiliated package, you should register
+  your package with the Astropy affiliated package registry. Instructions for
+  doing this will be provided on the `Astropy`_ website.
+
+* Good luck with your code and your science!
+
+.. _Astropy: http://www.astropy.org/
+.. _git: http://git-scm.com/
+.. _github: http://github.com
+.. _Cython: http://cython.org/