astropy/astropy

Astronomy and astrophysics core library

Astropy

The Astropy Project (http://astropy.org/) is a community effort to develop a single core package for Astronomy in Python and foster interoperability between Python astronomy packages. This repository contains the core package which is intended to contain much of the core functionality and some common tools needed for performing astronomy and astrophysics with Python.

Releases are registered on PyPI, and development is occurring at the project's GitHub page.

For installation instructions, see the online documentation or docs/install.rst in this source distribution.

Contributing Code, Documentation, or Feedback

The Astropy Project is made both by and for its users, so we welcome and encourage contributions of many kinds. Our goal is to keep this a positive, inclusive, successful, and growing community by abiding with the Astropy Community Code of Conduct.

More detailed information on contributing to the project or submitting feedback can be found on the contributions page. A summary of contribution guidelines can also be used as a quick reference when you are ready to start writing or validating code for submission.

Getting started with GitHub Codespaces

Codespaces is a cloud development environment supported by GitHub. None of the Astropy build machinery depends on it, but it is a convenient way to quickly get started doing development on Astropy.

To get started, create a codespace for this repository by clicking this 👇

A codespace will open in a web-based version of Visual Studio Code. The dev container is fully configured with software needed for this project. Feel free to take a look at GitHub Codespaces Support page for help.

Note: Dev containers is an open spec which is supported by GitHub Codespaces and other tools.

Supporting the Project

The Astropy Project is sponsored by NumFOCUS, a 501(c)(3) nonprofit in the United States. You can donate to the project by using the link above, and this donation will support our mission to promote sustainable, high-level code base for the astronomy community, open code development, educational materials, and reproducible scientific research.

License

Astropy is licensed under a 3-clause BSD style license - see the LICENSE.rst file.

If you locally cloned this repo before 7 Apr 2021

The primary branch for this repo has been transitioned from master to main. If you have a local clone of this repository and want to keep your local branch in sync with this repo, you'll need to do the following in your local clone from your terminal:

git fetch --all --prune
# you can stop here if you don't use your local "master"/"main" branch
git branch -m master main
git branch -u origin/main main

If you are using a GUI to manage your repos you'll have to find the equivalent commands as it's different for different programs. Alternatively, you can just delete your local clone and re-clone!

astropy's Issues

implement data.astropy.org server with version hashes

The current config.data package expects to be looking in data.astropy.org to find remote data files... and such a server does not yet exist. It should carry necessary data that we don't want in the source code, and should also support specific versions of files via data.astropy.org/hash/395dd6493cc584df1e78b474fb150840.

wcs build error on Mac OS X Lion

python setup.py install --user

results in an error while trying to install the astropy.wcs._wcs extension (see below).
Is this a known problem with llvm-gcc-4.2 or one specific to the wcs version included in astropy?

In file included from /Users/deil/git/astropy/astropy/wcs/src/wcslib/C/wcs.c:44:
/Users/deil/git/astropy/astropy/wcs/src/wcslib/C/wcsutil.h:227: warning: function declaration isn't a prototype
/Developer/usr/bin/llvm-gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -pipe -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DECHO -DWCSTRIG_MACRO -DASTROPY_WCS_BUILD -D_GNU_SOURCE -DWCSVERSION=4.8.2 -DNDEBUG -UDEBUG -I/Users/deil/Library/Python/2.7/lib/python/site-packages/numpy/core/include -I/Users/deil/git/astropy/astropy/wcs/src/wcslib/C -I/Users/deil/git/astropy/astropy/wcs/src -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c /Users/deil/git/astropy/astropy/wcs/src/wcslib/C/wcserr.c -o build/temp.macosx-10.7-x86_64-2.7/Users/deil/git/astropy/astropy/wcs/src/wcslib/C/wcserr.o
/Users/deil/git/astropy/astropy/wcs/src/wcslib/C/wcserr.c:140: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
{standard input}:0:End-of-File not at end of a line
{standard input}:116:End-of-File not at end of a line
{standard input}:unknown:Partial line at end of file ignored
{standard input}:unknown:Undefined local symbol L_.str
{standard input}:unknown:Undefined local symbol L_.str1
{standard input}:unknown:Undefined local symbol L_.str2
error: command '/Developer/usr/bin/llvm-gcc-4.2' failed with exit status 1

Implement astropy.units sub-package

This issue is to indicate that a units sub-package should be implemented before the 0.1.0 release if possible.

@perrygreenfield has already provided an example implementation in #126.

VO build error on OS X Lion

I'm getting the follow error trying to build the latest astropy on Lion:

astropy 54 >:python setup.py build
running build
running build_py
running build_ext
building 'astropy.io.vo.iterparser' extension
gcc-4.2 -DNDEBUG -g -O3 -O -ansi -DHAVE_EXPAT_CONFIG_H=1 -DBYTEORDER=1234 -DHAVE_UNISTD_H -Iastropy/io/vo/src -Icextern/expat/lib -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c astropy/io/vo/src/iterparse.c -o build/temp.macosx-10.6-intel-2.7/astropy/io/vo/src/iterparse.o
astropy/io/vo/src/iterparse.c:268: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PyObject'
astropy/io/vo/src/iterparse.c: In function 'startElement':
astropy/io/vo/src/iterparse.c:416: warning: passing argument 3 of 'PyTuple_SetItem' makes pointer from integer without a cast
astropy/io/vo/src/iterparse.c: In function 'endElement':
astropy/io/vo/src/iterparse.c:495: warning: passing argument 3 of 'PyTuple_SetItem' makes pointer from integer without a cast
error: command 'gcc-4.2' failed with exit status 1

I can get that particular command to work if I remove the -ansi flag.

Also, setup.py does not sense that I have Lion, I have to manually export CC=gcc-4.2 so that wcs will build.

no module named version in setup.py

Hi Guys,

I fetched from upstream (just now) and it seemed to have started out in the right direction, but then met an unfortunate end:

python setup.py develop
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.19.tar.gz
Extracting in /var/folders/zc/cbprg2bj1l50c3y6sfzf64wm0000gn/T/tmpXuKWeL
Now working in /var/folders/zc/cbprg2bj1l50c3y6sfzf64wm0000gn/T/tmpXuKWeL/distribute-0.6.19
Building a Distribute egg in /Users/wkerzend/scripts/python/astropy
/Users/wkerzend/scripts/python/astropy/distribute-0.6.19-py2.7.egg
Traceback (most recent call last):
  File "setup.py", line 13, in <module>
    import astropy
  File "/Users/wkerzend/scripts/python/astropy/astropy/__init__.py", line 3, in <module>
    from astropy.version import version as __version__
ImportError: No module named version

I have never tried python setup.py develop before but I heard it somehow sets the package path so I can continue to developing while my astropy is in its place.

Cheers
Wolfgang

Auto-generate config files

The config package interacts with packages now to use a single configuration file that it updates as configuration settings are changed programatically, but it would be good to have it automatically make a new config file populated with all of the default settings. The config.configs._generate_all_config_items function does this, but it needs to be hooked into the setup.py or some other sort of interfaces that makes this happen in some fairly smart automatic way.

astropy.org shows outdated sphinx docs

At the moment astropy.org shows an old version of the sphinx docs.

Would it be helpful if I make a very small page that simply points to the up-to-date Read the Docs page and Github using the IPython layout?
Or is someone already working on a web page for astropy.org?

http://ipython.org/
https://github.com/ipython/ipython-website

Make build_sphinx use _build directory

This has been discussed in #102, #115, and #117. Basically, the python setup.py build_sphinx command should use the version of astropy that is in the _build directory, and make html in the docs directory should use whatever version is actually installed.

Note that this should be done after #115, because there will probably be quite a bit of incompatible changes.

Update py.test to stable 2.2

@jiffyclub - could you update the py.test bundle to stable 2.2? This will allow parametrized tests using decorators.

Use a temporary directory for $HOME/.astropy in config tests

As suggested by @mdboom and @iguananaut in issue #123, the tests for the config sub-package should not alter the user's actual $HOME/.astropy directory. So the tests should be updated to use a temporary directory (probably using py.test's tmpdir mechanism).

Running tests using py.test command-line script

I've tried running the tests using the command-line py.test script with version 4ddb3d7 of the core astropy repository:

git clone git://github.com/astropy/astropy.git astropy_testing
cd astropy_testing
cd astropy
py.test

If I do this, then 809 tests fail. I just wanted to check whether this is ok, or whether this should skip tests that can not be run without compiling (i.e. should it be mostly skipped tests rather than failures).

astropy.config.data._find_pkg_data_fn() generates tons of ImportWarnings

In [1]: import warnings

In [2]: warnings.simplefilter('always')

In [4]: from astropy.config import get_data_fileobj

In [5]: get_data_fileobj("astropy/wcs/tests/data/3d_cd.hdr")
astropy/wcs/tests/data
/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory '/home/mdboom/Work/builds/astropy/astropy/wcs/tests/data': missing __init__.py
  file, filename, etc = imp.find_module(subname, path)
/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory '/home/mdboom/python/lib/python2.7/site-packages/astropy-0.0dev_r455-py2.7-linux-x86_64.egg/astropy/wcs/tests/data': missing __init__.py
  file, filename, etc = imp.find_module(subname, path)
/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory '/home/mdboom/python/lib/python2.7/site-packages/astropy-0.0dev_r455-py2.7-linux-x86_64.egg/astropy/wcs/tests/data': missing __init__.py
  file, filename, etc = imp.find_module(subname, path)
/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory 'astropy/wcs/tests/data': missing __init__.py
  file, filename, etc = imp.find_module(subname, path)
/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory '/home/mdboom/python/local/lib/python2.7/site-packages/astropy-0.0dev_r455-py2.7-linux-x86_64.egg/astropy/wcs/tests/data': missing __init__.py
  file, filename, etc = imp.find_module(subname, path)
/usr/lib/python2.7/pkgutil.py:186: ImportWarning: Not importing directory '/home/mdboom/python/lib/python2.7/site-packages/astropy-0.0dev_r455-py2.7-linux-x86_64.egg/astropy/wcs/tests/data': missing __init__.py
  file, filename, etc = imp.find_module(subname, path)
astropy/wcs/tests
Out[5]: <open file '/home/mdboom/Work/builds/astropy/astropy/wcs/tests/data/3d_cd.hdr', mode 'rb' at 0x14c2f60>

It would be great if no warnings were generated. It's not clear to me why anything needs to be imported just to find the data files relative to the source files.

Error when generating WCS documentation

When build the latest docs, I get the following error:

Traceback (most recent call last):wcsprm                                        
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sphinx/ext/autodoc.py", line 321, in import_object
    __import__(self.modname)
ImportError: No module named _wcs

/Users/tom/tmp/astropy/docs/wcs/api_wcsprm.rst:14: WARNING: autodoc can't import/find class 'astropy.wcs._wcs.Tabprm', it reported error: "No module named _wcs", please check your spelling and sys.path

Read the Docs search not working?

The Read the Docs search field in the sidebar does seem pretty useless, e.g. there are no results for 'astropy' or 'wcs':
http://readthedocs.org/docs/astropy/en/latest

It is possible to search the docs sphinx-style by explicitly going to
http://readthedocs.org/docs/astropy/en/latest/search.html

but I think it would be nice / most users would expect a search field with this functionality in the sidebar,
as is the case with most other sphinx-generated documentations outside Read the Docs?

Note that this is not an astropy issue, I looked at a few other projects and there it is the same.
I think this issue is unrelated, but I'm not sure:
readthedocs/readthedocs.org#138

If someone else thinks it would be nice to have the usual sphinx search for the project in the sidebar I can investigate further if this is possible with Read the Docs or make a feature request with them.

Implement astropy.coords sub-package

This issue is to indicate that a coords sub-package should be implemented before the 0.1.0 release if possible

Passing python setup.py test options to py.test

py.test has some useful options, for example to output the tests in JUnit XML format (useful e.g. for Jenkins):

py.test -v --junitxml junit.xml

Since the primary way of running tests in astropy is via:

python setup.py test

I was wondering whether we should pass any options that are not already catched in astropy_test directly to py.test? Alternatively, could we hardcode the junit option above?

@jiffyclub, @eteq, @mdboom, @iguananaut - any thoughts?

Add astropy.config.get_data_dir()?

There are a few tests in wcs that look in a directory, glob its contents and the loads each file to test that it loads correctly.

It would be nice to have a astropy.config.get_data_dir() function to do this globbing. Of course, that wouldn't work remotely (or maybe it could be made to work if directory listings are turned on on the web server), but even without remote support it would be helpful to replace all of the __file__ magic currently being used.

Bug with Header.fromTxtFile

As of PyFITS 3.0.5 and astropy.fits, the following header cannot be read in correctly:

SIMPLE  =                    T /
BITPIX  =                  -32 /
NAXIS   =                    3 /
NAXIS1  =                   11 /
NAXIS2  =                   12 /
NAXIS3  =                   32 /
EXTEND  =                    T /
CRVAL1  =        57.6599999999 /
CRPIX1  =       -799.000000000 /
CDELT1  =    -0.00638888900000 /
CTYPE1  = 'RA---SFL'           /
CRVAL2  =        0.00000000000 /
CRPIX2  =       -4741.91300000 /
CDELT2  =     0.00638888900000 /
CTYPE2  = 'DEC--SFL'           /
CRVAL3  =       -9959.44378305 /
CRPIX3  =              1.00000 /
CDELT3  =        66.4236100000 /
CTYPE3  = 'VELO-LSR'           /

For example, using:

from astropy.io import fits
h = fits.Header()
h.fromTxtFile('cube.hdr')

produces the following Exception:

Traceback (most recent call last):
  File "test.py", line 8, in <module>
    h.fromTxtFile('cube.hdr')
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/util.py", line 212, in deprecated_func
    return func(*args, **kwargs)
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/header.py", line 1770, in fromTxtFile
    padding=False)
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/header.py", line 395, in fromfile
    return cls.fromstring(blocks, sep=sep)
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/header.py", line 312, in fromstring
    return cls(cards)
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/header.py", line 92, in __init__
    self.append(card, end=True)
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/header.py", line 1036, in append
    if str(card) == blank:
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/card.py", line 435, in __str__
    return self.image
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/card.py", line 613, in image
    self.verify('silentfix')
  File "/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev843-py2.7-macosx-10.6-x86_64.egg/astropy/io/fits/verify.py", line 65, in verify
    raise VerifyError('\n' + x)
astropy.io.fits.verify.VerifyError: 
Card image is not FITS standard (unparsable value string: T /
BITPIX  =                  -32 /
NAXIS   =).  Fixed card to meet the FITS standard: SIMPLE
Unfixable error: Unprintable string '\nBITPIX  =                  -32 /\nNAXIS   ='

Clarify information about legacy packages

Upon running python setup.py install I got the following messages about astropy's compatibility layer. Sorry I haven't been following the details, but I don't know quite what this implies. Certainly the average user will be confused. Is there a problem if I do nothing? If I uninstall my pyfits and re-install astropy, will "import pyfits" still work?

(astropy27)ccosmos$ python setup.py install
------------------------------------------------------------
The legacy package 'pyfits' was found.
To install astropy's compatibility layer instead, uninstall
'pyfits' and then reinstall astropy.
------------------------------------------------------------
------------------------------------------------------------
The legacy package 'pywcs' was found.
To install astropy's compatibility layer instead, uninstall
'pywcs' and then reinstall astropy.
------------------------------------------------------------

io.fits should return table data as Astropy Tables

This issue here as a reminder that this work needs to be done at some point (there's also a ticket for this in PyFITS' tracker). Currently PyFITS/astropy.io.fits has its own custom array class for representing FITS table data. Since FITS tables do have a few "special" features it will probably still be necessary to have a special class specifically for FITS tables, though for the sake of consistency it should at least be based on the Astropy Table class (which is a lot cleaner and more usable than what PyFITS currently has anyways).

This won't be doable for the first release--it's a big change and will be very difficult, if not impossible, to implement in a backwards compatible manner. For the first release it's probably better that astropy.io.fits (not to mention the pyfits legacy shim) work as a drop-in replacement for PyFITS.

This work will also have to be backported to PyFITS, so I'll want to tie it to an eventual PyFITS release.

sdist doesn't include wcs header files and scripts directory.

Hello,

I tried Python 2.6 and Python 2.7. Running python setup.py install in the astropy repo, doesn't create any problems since all the files are accessible. But this is a problem when trying to install this from a sdist, for example by automated testing software like tox.

Bug in setuptools/distutils?

Using recursive-include astropy/wcs/src *.h in MANIFEST.in works.

If MANIFEST.in is specified then only the files mentioned in it gets copied; setuptools/distutils does not use its default file finding algorithm in this case.

Additional comments (with what I think are the reasons):

The scripts directory doesn't get copied, since setup.py removes the only file README.rst in this directory.

The contents of AstroPy.egg-info/ doesn't get cleared/updated between two runs of setup.py. For example, say we run setup.py sdist using the MANIFEST.in mentioned above. Now remove the line from MANIFEST.in, ad run setup.py again. This time the header files will get included, even though they are not specified in MANIFEST.in. I guess that this is because the header files get listed in AstroPy.egg-info/SOURCES.txt the first time, and the list gets reused. This leads to major confusion: I just lost 1.5 hours. Deleting AstroPy.egg-info leads to the previous behaviour.

If AstroPy.egg-info is deleted, without deleting version.py AND version.pyc, then the import astropy line in setup.py complains that AstroPy distribution doesn't exist. The astropy/__init__.py tried to run version.py which uses AstroPy, causing error.

Prasanth

Support both new and old-style string formatting in Table

See the discussion in #130 - it would be great if there was a way to intelligently determine what style of format string the user was using, and use the s % fmt or s.fromat(fmt) syntax, appropriately.

problem with affiliate package setup.py

Hi guys,

I tried the following today with https://github.com/wkerzendorf/specutils/blob/master/setup.py and this happened. You guys probably know what's going on. If not I can debug this further.

Wolfgangs-MacBook-Pro:specutils wkerzend$ python setup.py develop
Freezing version number to specutils/version.py
Traceback (most recent call last):
  File "setup.py", line 41, in <module>
    setup_helpers.get_debug_option())
  File "/Users/wkerzend/scripts/python/astropy/astropy/version_helper.py", line 204, in generate_version_py
    f.write(_get_version_py_str(packagename, version, release, debug))
  File "/Users/wkerzend/scripts/python/astropy/astropy/version_helper.py", line 158, in _get_version_py_str
    major, minor, bugfix = _version_split(version)
  File "/Users/wkerzend/scripts/python/astropy/astropy/version_helper.py", line 37, in _version_split
    bugfix = 0 if len(versplit) < 3 else int(versplit[2])
ValueError: invalid literal for int() with base 10: ''

astropy != AstroPy ???

Is there a good reason for the distutils/setuptools/egg name being different from the Python package name? It's currently defined as "AstroPy" in the setup.py.

Maybe this doesn't matter (sorry to be pedantic), but I find this confusing for the following reasons:

1. I use a tool that cleans my virtualenv by deleting packages by name -- if its name on disk is different from how it's imported I have to remember which is which

2. "pip install AstroPy" someday will confuse people

3. tarballs and installers built with distutils won't match the name of the git repository

Issue with pastebin option in astropy.test() with Python 3.2

As of 7946471, when using astropy.test(pastebin='failed'), an exception related to XML is raised:

============================================================================ Sending information to Paste Service =============================================================================
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
/Users/tom/<ipython-input-3-144d52ea8b0a> in <module>()
----> 1 astropy.test(pastebin='failed')

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/tests/helper.py in run_tests(module, args, plugins, verbose, pastebin, remote_data)
    121         all_args += ' --remotedata'
    122 
--> 123     return pytest.main(args=all_args, plugins=plugins)
    124 
    125 

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in main(args, plugins)
    455         config = hook.pytest_cmdline_parse(
    456                 pluginmanager=_pluginmanager, args=args)
--> 457         exitstatus = hook.pytest_cmdline_main(config=config)
    458     except UsageError:
    459         e = sys.exc_info()[1]

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in __call__(self, **kwargs)
    409     def __call__(self, **kwargs):
    410         methods = self.hookrelay._pm.listattr(self.name)
--> 411         return self._docall(methods, kwargs)
    412 
    413     def pcall(self, plugins, **kwargs):

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in _docall(self, methods, kwargs)
    420         mc = MultiCall(methods, kwargs, firstresult=self.firstresult)
    421         try:
--> 422             res = mc.execute()
    423             if res:
    424                 self.trace("finish", self.name, "-->", res)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in execute(self)
    338             method = self.methods.pop()
    339             kwargs = self.getkwargs(method)
--> 340             res = method(**kwargs)
    341             if res is not None:
    342                 self.results.append(res)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.main in pytest_cmdline_main(config)
     88 
     89 def pytest_cmdline_main(config):
---> 90     return wrap_session(config, _main)
     91 
     92 def _main(config, session):

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.main in wrap_session(config, doit)
     82     if initstate >= 2:
     83         config.hook.pytest_sessionfinish(session=session,
---> 84             exitstatus=session.exitstatus)
     85     if initstate >= 1:
     86         config.pluginmanager.do_unconfigure(config)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in __call__(self, **kwargs)
    409     def __call__(self, **kwargs):
    410         methods = self.hookrelay._pm.listattr(self.name)
--> 411         return self._docall(methods, kwargs)
    412 
    413     def pcall(self, plugins, **kwargs):

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in _docall(self, methods, kwargs)
    420         mc = MultiCall(methods, kwargs, firstresult=self.firstresult)
    421         try:
--> 422             res = mc.execute()
    423             if res:
    424                 self.trace("finish", self.name, "-->", res)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in execute(self)
    338             method = self.methods.pop()
    339             kwargs = self.getkwargs(method)
--> 340             res = method(**kwargs)
    341             if res is not None:
    342                 self.results.append(res)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.terminal in pytest_sessionfinish(self, exitstatus, __multicall__)
    316             self.summary_errors()
    317             self.summary_failures()
--> 318             self.config.hook.pytest_terminal_summary(terminalreporter=self)
    319         if exitstatus == 2:
    320             self._report_keyboardinterrupt()

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in __call__(self, **kwargs)
    409     def __call__(self, **kwargs):
    410         methods = self.hookrelay._pm.listattr(self.name)
--> 411         return self._docall(methods, kwargs)
    412 
    413     def pcall(self, plugins, **kwargs):

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in _docall(self, methods, kwargs)
    420         mc = MultiCall(methods, kwargs, firstresult=self.firstresult)
    421         try:
--> 422             res = mc.execute()
    423             if res:
    424                 self.trace("finish", self.name, "-->", res)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.core in execute(self)
    338             method = self.methods.pop()
    339             kwargs = self.getkwargs(method)
--> 340             res = method(**kwargs)
    341             if res is not None:
    342                 self.results.append(res)

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.pastebin in pytest_terminal_summary(terminalreporter)
     49         if tr.config.option.debug:
     50             terminalreporter.write_line("xmlrpcurl: %s" %(url.xmlrpc,))
---> 51         serverproxy = getproxy()
     52         for rep in terminalreporter.stats.get('failed'):
     53             try:

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/_pytest.pastebin in getproxy()
     39 
     40 def getproxy():
---> 41     return py.std.xmlrpclib.ServerProxy(url.xmlrpc).pastes
     42 
     43 def pytest_terminal_summary(terminalreporter):

/Users/tom/Library/Python/3.2/lib/python/site-packages/astropy-0.0dev_r255-py3.2-macosx-10.6-x86_64.egg/astropy/extern/pytest.py/py._std in __getattr__(self, name)
     13             m = __import__(name)
     14         except ImportError:
---> 15             raise AttributeError("py.std: could not import %s" % name)
     16         return m
     17 

AttributeError: py.std: could not import xmlrpclib

@jiffyclub - Is this fixable, or do we need to report this as a bug in py.test?

Implement astropy.time sub-package

This issue is to indicate that a time sub-package should be implemented before the 0.1.0 release if possible

Merge latest fixes from pyfits before 0.1 release

This issue serves as a general reminder for me to merge/test any unmerged bug fixes from PyFITS into astropy.io.fits prior to the 0.1 release.

io.ascii outputs recarray

@eteq wrote "I was trying out astropy.io.ascii.read today,
and I noticed that it's returning a numpy.core.records.recarray
rather than an astropy.table.Table. Is that intended behavior? It
seems like after all the trouble to implement the table, it makes
sense to have the reader functions use that class... Or is it
backwards-compatibility with asciitable thing?"

This documents an issue with a known fix. Will be fixed in the next set of io.ascii commits.

Issue when multiple conftest.py files are in the tree

I'm running into some issues with running tests in a specific environment (Jenkins + virtualenv) and I've finally figured out to how reproduce it:

git clone git://github.com/astropy/astropy.git
cd astropy/
mkdir directory
cd directory/
git clone git://github.com/astropy/astropy.git
cd astropy/
python setup.py test

which fails with the following error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "astropy/tests/helper.py", line 149, in run_tests
    return pytest.main(args=all_args, plugins=plugins)
  File "_pytest.core", line 467, in main
  File "_pytest.core", line 460, in _prepareconfig
  File "_pytest.core", line 419, in __call__
  File "_pytest.core", line 430, in _docall
  File "_pytest.core", line 348, in execute
  File "_pytest.helpconfig", line 25, in pytest_cmdline_parse
  File "_pytest.core", line 348, in execute
  File "_pytest.config", line 10, in pytest_cmdline_parse
  File "_pytest.config", line 345, in parse
  File "_pytest.config", line 75, in parse_setoption
  File "_pytest.config", line 70, in parse
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1039, in add_options
    self.add_option(option)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1020, in add_option
    self._check_conflict(option)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 995, in _check_conflict
    option)
optparse.OptionConflictError: option --remote-data: conflicting option string(s): --remote-data

This is because py.test imports the plugins twice because it finds them in astropy/conftest.py and astropy/directory/astropy/conftest.py. This is precisely what happens in Jenkins - there is a checkout of astropy inside another checkout of astropy. So is there a way to make sure that py.test stops e.g. at the first conftest.py? Or can we ensure that we catch the exception in pytest_addoption? What if we start picking up plugins from other projects instead of astropy? Can we restrict how far py.test searches for conftest.py files?

@mdboom - this is the issue I emailed you about yesterday (I was still confused as to the cause at the time). I'm also cc-ing @jiffyclub, @eteq, and @iguananaut.

Any ideas?

subprocess.check_output doesn't exist

In line 204 of setup_helpers.py:

 output = subprocess.check_output(c.compiler + ['--version'])

leads to AttributeError: 'module' object has no attribute 'check_output'.

Is this subprocess.check_call()?

Consistent scheme for file/directory locking

We should have a function/class in utils that can be used to lock files or directories to enable thread/process-safe file access. @mdboom pointed out http://code.google.com/p/pylockfile/ as a good place to look for the way we want to do this (perhaps even just pull it into extern).

Once this is done, these packages (and possibly others I'm not aware of) should be updated to use it:

• astropy.config.data
• astropy.config.configs (maybe?)
• astropy.vo
• astropy.io.fits (not yet in master)

Table pretty printer

Add functionality to output a table nicely using the defined format attributes, probably using the io.ascii fixed width table functionality.

Should this be Table.__str__ or something else like Table.print?

Integrate Python 3 compatibility functions

The Python 3 compatibility hacks in wcs, vo and fits should be merged. This will also form the basis for use by future code.

Since io.fits aka pyfits probably has the largest amount of this kind of stuff, it probably makes sense to do this after fits is merged in.

ImportError in wcs/setup_package.py

I am getting this error trying to build astropy:

astropy 32 >:python setup.py develop
Freezing version number to astropy/version.py
Traceback (most recent call last):
  File "setup.py", line 55, in <module>
    extensions.extend(package.get_extensions())
  File "/Users/jiffyclub/astropy/astropy/wcs/setup_package.py", line 169, in get_extensions
    from astropy.version import debug
ImportError: cannot import name debug

Support overriding config options via environment variables

I first wrote this as a comment in #35, but I'm creating a separate issue for this so it doesn't get forgotten. I will volunteer to implement it. This is slightly higher priority now that I'm getting somewhere with PyFITS implementation, and I would like to hook it into the eventual config system.

It would be good to have the ability to override any config options via environment variables. These environment variables would follow some standard naming convention like ASTROPY_SUB_PACKAGE_OPTION. There could also be some way to register shorter aliases for commonly used options, but I don't have any thoughts yet on the specifics of that.

In order to support these environment variables transparently, the easiest approach I see (which I usually end up doing anyways) is to provide a simple wrapper around ConfigObj objects. I like to use something simple like Configuration. This is a much simpler object than the ConfigObj so that fewer details of reading/writing the configuration are exposed to subpackage/affiliated package authors. It would still provide a dictionary-like interface and many of the methods of ConfigObj. Though rather than write() it has a save() method which I think is a little more obvious. If a user wants to update the configuration they simply call config.save(). This method would prevent saving any values that were overridden by environment variables.

Using a wrapper can have other eventual benefits, since it allows us to provide some abstractions around the configuration object that aren't specific to any one backend implementation (not that I would suggest we move away from ConfigObj or anything--it's just nice to have additional flexibility).

When to install compatibility packages

I'm confused by the Astropy behavior with compatibility packages. At the moment, if I have the genuine pyfits installed, and no astropy installation, astropy installs the legacy shim. If the legacy shim is already installed, it doesn't install it. This seems to be contradictory with the warning message:

------------------------------------------------------------
The legacy package 'vo' was found.
To install astropy's compatibility layer instead, uninstall
'vo' and then reinstall astropy.
------------------------------------------------------------

which suggests to me that the correct behavior is that if the real PyFITS is installed ('legacy package'), then the shim should not be installed, and that if people want the shim, they should uninstall the real package. However, if the installed pyfits is the legacy shim, then it should be re-installed in case it has been updated. Is that not the intended behavior? If so, the following code has the wrong logic:

found_legacy_module = False
try:
    location = imp.find_module(old_package)
except ImportError:
    pass
else:
    # We want ImportError to raise here, because that means it was
    # found, but something else went wrong.

    # We could import the module here to determine if its "real"
    # or just a legacy alias.  However, importing the legacy alias
    # may cause importing of code within the astropy source tree,
    # which may require 2to3 to have been run.  It's safer to just
    # open the file and search for a string.
    filename = os.path.join(location[1], '__init__.py')
    if os.path.exists(filename):
        with open(filename, 'U') as fd:
            if '_is_astropy_legacy_alias' in fd.read():
                found_legacy_module = True

shim_dir = os.path.join(get_legacy_alias_dir(), old_package)

if found_legacy_module:
    warn('-' * 60)
    warn("The legacy package '{0}' was found.".format(old_package))
    warn("To install astropy's compatibility layer instead, uninstall")
    warn("'{0}' and then reinstall astropy.".format(old_package))
    warn('-' * 60)

    if os.path.isdir(shim_dir):
        shutil.rmtree(shim_dir)
    return (None, None)

I think it should be:

if '_is_astropy_legacy_alias' not in fd.read():

Tests create .astropy directory

Because #187 makes it straightforward to run tests without any install, it's problematic that the tests create the astropy configuration directory (~/.astropy by default). This is probably fixable with some clever py.test tricks to fool the tests into using a temporary directory as the configuration directory.

wcs.WCS.wcs.name is not set

I tried the two examples here:
http://readthedocs.org/docs/astropy/en/latest/wcs/examples.html

In both cases I get an empty string for the name:

# Print out the "name" of the WCS, as defined in the FITS header
print w.wcs.name

Is that normal (then why bother printing it in these examples) or a bug?
All astropy tests pass successfully.

Improve version.py generation

I've been working on my own version.py generation for STScI's packages--it works pretty similarly, but with a couple differences:

• I also started out making it an extension of the build_py command, but I ended up changing it to regenerate the file on every setup.py run--this ensures that an updated version.py file is created for commands such as 'develop' and 'sdist'. It doesn't seem to add any noticeable time to running setup.py.
• The version.py uses the SVN revision info getter to automatically update its SVN info on import if the package is installed in develop mode. That way, when installed in develop mode the revision is always up to date. I would want the same for git. It doesn't do this if the package is not installed in develop mode, so it doesn't hurt import time otherwise. The code for doing that is just part of the version.py template.

I'm open to other ideas for exactly how to implement this, but I would want to add these capabilities.

Documentation re-organization/homogenization

The current Sphinx documentation needs to be improved to make it more homogeneous (since a lot of the current docs were pulled in from existing projects). In a lot of cases, the import statements could be improved, e.g.

>>> import astropy.io.fits
>>> hdulist = astropy.io.fits.open('input.fits')

could be better written as:

>>> from astropy.io import fits
>>> hdulist = fits.open('input.fits')

Docstrings must be at the top to be picked up by help()

>>> import astropy
>>> help(astropy)
>>> astropy? # in ipython

includes the license info in the name and doesn't pick up the docstring.

The same problem is e.g. present in astropy.config, whereas e.g. astropy.wcs or wcs.constants work fine.
I didn't check the other modules.

The solution is to always put the docstring at the top right after the license info.

3 vo tests failing on py 3.2.1

I ran the tests with python 3.2.1 on Mac OS X 10.6, and 3 of the VO-related tests failed. Shining Panda seems fine, so this might be Mac specific (or something peculiar to me). URLs for tracebacks are below. The last time I tried in python 3 these weren't happening, but that was probably several weeks ago...

http://paste.pocoo.org/show/530200
http://paste.pocoo.org/show/530201
http://paste.pocoo.org/show/530202

Interoperability between astropy.wcs and legacy pyfits

The following example demonstrates something that does not work:

In [1]: import pyfits

In [2]: h = pyfits.getheader('.../2MASS_k.fits.gz')

In [3]: from astropy import wcs

In [4]: w = wcs.WCS(h)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/Users/tom/<ipython-input-4-dcd57af92df8> in <module>()
----> 1 w = wcs.WCS(h)

/Users/tom/Library/Python/2.7/lib/python/site-packages/astropy-0.0.dev989-py2.7-macosx-10.6-x86_64.egg/astropy/wcs/wcs.pyc in __init__(self, header, fobj, key, minerr, relax, naxis, keysel, colsel, fix)
    250             else:
    251                 raise TypeError(
--> 252                     "header must be a string or an astropy.io.fits.Header "
    253                     "object")
    254             try:

TypeError: header must be a string or an astropy.io.fits.Header object

but it might be nice if it could work, as some people may have the real PyFITS package installed, but the PyWCS legacy shim installed. This is not a major issue, but it may confuse users.

Add support for masking/null values to Table class

The table docs say: "At this time the astropy.table package has no support for masking and null values. This is to be done." This issue simply records that desire in the issue system.

Test legacy shims

This is basically a placeholder.

It would be nice to run the tests from "legacy" packages against the legacy shims in astropy. To do this properly will require some serious package namespace voodoo magic, but it would be nice to have a way to determine how backward compatible these legacy shims really are. (While care has been taken to maintain a consistent interface, some divergence has already happened in the name of better integration with other parts of astropy etc.)

io.ascii tests broken with numpy-dev

It looks like some io.ascii tests are broken when using the developer version of Numpy with Python 3.2: https://jenkins.shiningpanda.com/astropy/job/astropy-py3.2-numpy-dev/lastCompletedBuild/testReport/

@mdboom - are the tests using the latest revision of Numpy?

Include PEP8 plugin in test framework

It was suggested by @wkerzendorf that we may want to have a convenient way to test pep8 compliance within our test framework. There is a py.test plugin for this here:

http://pypi.python.org/pypi/pytest-pep8

It does seem configurable so we can turn off some of the more annoying false-positive warnings off if necessary.

Optional dependency checker tool

At the Boston meeting, it was discussed that there would be a tool to check for optional dependencies, list the versions that were found and, where possible, install them. I'm assigning @eteq, because I believe he already has a similar tool in Astropysics.

Implement affiliated package registry

The Astropy vision states that Affiliated packages will be listed in a central location (in addition to PyPI) that will allow an easy installation of all the affiliated packages, for example with a script that will seamlessly download and install all the affiliated packages. The core package will also include mechanisms to facilitate this installation process.

An easy way to do this would be to simply have a file in the astropy.github.com repository containing a list of affiliated packages with names, URLs, etc., as a JSON file. This file can then be accessed by an affiliated package installer. This also means that affiliated packages are added to the JSON file through proper commits to the astropy.github.com repository, which prevents anyone from registering a package. I can take a stab at this, unless anyone has a better idea for how to implement this?

Add legacy package for io.ascii to asciitable

Add legacy package to package_setup.py for io.ascii to map to asciitable. (Pending pull request #174).