astropy / astropy Goto Github PK
View Code? Open in Web Editor NEWAstronomy and astrophysics core library
Home Page: https://www.astropy.org
License: BSD 3-Clause "New" or "Revised" License
Astronomy and astrophysics core library
Home Page: https://www.astropy.org
License: BSD 3-Clause "New" or "Revised" License
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
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 ='
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: ''
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')
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?
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():
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.
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.
------------------------------------------------------------
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
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.
@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.
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?
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).
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.
Add legacy package to package_setup.py for io.ascii to map to asciitable. (Pending pull request #174).
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.
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
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?
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.
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
.
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.
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:
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
"pip install AstroPy" someday will confuse people
tarballs and installers built with distutils won't match the name of the git repository
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.
This issue is to indicate that a coords sub-package should be implemented before the 0.1.0 release if possible
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:
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).
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.
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
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()
?
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
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?
>>> 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.
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.
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
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.
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.
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.)
@jiffyclub - could you update the py.test bundle to stable 2.2? This will allow parametrized tests using decorators.
I've been working on my own version.py generation for STScI's packages--it works pretty similarly, but with a couple differences:
I'm open to other ideas for exactly how to implement this, but I would want to add these capabilities.
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
?
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.
This issue is to indicate that a time sub-package should be implemented before the 0.1.0 release if possible
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.
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.
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.
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?
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.
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.
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
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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.