From kellecruz at gmail.com  Sun May  5 23:28:05 2013
From: kellecruz at gmail.com (Kelle Cruz)
Date: Sun, 5 May 2013 23:28:05 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
Message-ID: <CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>

I *hate* that the answer to this question changes so often! Is there any
hope of it settling down anytime soon?

Is someone planning on updating the python4astronomers install page? I've
been considering that page the "official" recommendation. Tom? I think the
only thing that needs to be updated is the box for the impatient?which is
almost EVERYONE!

kelle


On Tue, Apr 30, 2013 at 11:29 AM, Leo Singer <lsinger at caltech.edu> wrote:

> I agree, MacPorts is the way to go. Enthought's 'Free' distribution is
> crippled; it's 32-bit, which limits speed and array sizes on modern 64-bit
> machines. MacPorts provides not just Python itself, but hundreds of Python
> packages, including many that are related to astronomy and other science
> disciplines.
>
> On Apr 30, 2013, at 10:16 AM, astropy-request at scipy.org wrote:
>
> *From: *"Ries, Paul A (3265-Affiliate)" <Paul.A.Ries at jpl.nasa.gov>
> *Subject: **Re: [AstroPy] Enthought Canopy vs. another distribution for
> Mac?*
> *Date: *April 30, 2013 10:21:35 AM CDT
> *To: *"AstroPy at scipy.org" <AstroPy at scipy.org>
>
>
>  Eric,
>
>  If you're familiar with linux package administration, I recommend using
> MacPorts ( http://www.macports.org/ ) to install your python.  It's very
> similar to the apt or yum system used on linux boxes.  It leaves your
> system python untouched, but lets you install pretty much any free python
> package out there and allows you to keep everything up to date. (It also
> works with plenty of other free and astronomically useful software e.g.
> gcc, gfortran ,editors).  It also provides simple instruction with
> installation for how to manage which python is used by default.   I dabbled
> in Enthought and the system python, but I've found Macports to more
> reliably reproduce the pain-free python experience from linux.
>
>  For more on installing with macports:
> http://astrofrog.github.io/macports-python/
>
>  Also, an aside, don't fret much about clobbering CASA.  It will happily
> stay in its own little python world regardless of what python you're
> installing.
>
>  ----Paul
>
>  On Apr 30, 2013, at 7:20 AM, Matt Davis wrote:
>
>  Hi Eric, I generally recommend the Anaconda distro:
> http://continuum.io/downloads.html It's open source and supports setting
> up different environments, and it's nicely self contained so it won't mess
> with anything else you have installed. You can set it up on both Mac and
> Linux without root.
>
>  Best,
> Matt
>
>  On Apr 30, 2013, at 10:13 AM, "Eric L. N. Jensen" <
> ejensen1 at swarthmore.edu>
>  wrote:
>
> Hi,
>
> I've gradually been making the switch both to using Python more for my
> data analysis, and also doing more of my work on a Mac rather than Linux.
>  So I've decided it's time to get my Mac python distribution(s) in order
> (there are several of them running around on my machine, from various
> packages) and start fresh with a new python distro that I'll maintain as my
> main work environment.
>
> The page at
> http://python4astronomers.github.io/installation/python_install.htmlrecommends Enthought Python as a good place to start, but I find that this
> has now changed to a different environment called Canopy.  Any opinions on
> whether I should install Canopy, or choose a different distro?
>
> A few pieces of information that may be helpful in answering this:
>
> 1.  I'm running Mac OSX 10.7, 64-bit.
> 2.  I'm comfortable installing/building software from the command line (as
> root or not).
> 3.  BUT all of my installation/sys-admin experience is with non-python
> software, and much of it on Linux.  I don't have any experience with
> managing a python environment, especially with multiple python
> installations, and I don't want to mess up the system python install (or
> the internal python installs for other software I have installed, like
> CASA).
> 4.  I *do* qualify for the Enthought academic license, so I can use that
> rather than the free version.
> 5.  If this goes well, I'd probably like to set up a similar environment
> on my linux machine as well, though this is relatively low priority if
> otherwise there's a good Mac-only solution.
>
> Thanks in advance for your help with this - let me know if there's other
> info that would be useful.
>
> Eric Jensen
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>  _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Kelle Cruz, PhD ? http://kellecruz.com/
917.725.1334 ? Hunter: x16486 ? AMNH: x3404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130505/8ad012b1/attachment.html>

From jzuhone at gmail.com  Sun May  5 23:39:09 2013
From: jzuhone at gmail.com (John ZuHone)
Date: Sun, 5 May 2013 23:39:09 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
Message-ID: <6F9D390F-E4C5-4220-A76B-5719A4F58675@gmail.com>

Hi all,

First off, I realize that most of the people writing on this thread are observers, and wouldn't think to install a Python distribution based on a simulation package necessarily.

I should mention, however, that the yt Project (http://yt-project.org), which is a Python-based toolkit for analyzing astrophysical simulations, has an installation script that installs a full-fledged Python distribution in your home directory (or wherever else you want it) along with a bunch of other useful packages, including:

NumPy
pip
IPython
SciPy (optional)
SymPy
etc.

It installs everything from source and puts it into its own directory. After setting this up, there's an activate script that will set up the appropriate environment variables. 

This works very well on most distributions of Linux and Mac OS X. After installing it, you can use pip to install a host of other Python packages, including AstroPy, which went off without a hitch for me. 

So, it's worth a look at, even if you don't plan on using yt itself. You can get the install script by going to:

http://yt-project.org/#getyt

Best,

John ZuHone

On May 5, 2013, at 11:28 PM, Kelle Cruz <kellecruz at gmail.com> wrote:

> I *hate* that the answer to this question changes so often! Is there any hope of it settling down anytime soon?
> 
> Is someone planning on updating the python4astronomers install page? I've been considering that page the "official" recommendation. Tom? I think the only thing that needs to be updated is the box for the impatient?which is almost EVERYONE!
> 
> kelle
> 
> 
> On Tue, Apr 30, 2013 at 11:29 AM, Leo Singer <lsinger at caltech.edu> wrote:
> I agree, MacPorts is the way to go. Enthought's 'Free' distribution is crippled; it's 32-bit, which limits speed and array sizes on modern 64-bit machines. MacPorts provides not just Python itself, but hundreds of Python packages, including many that are related to astronomy and other science disciplines.
> 
> On Apr 30, 2013, at 10:16 AM, astropy-request at scipy.org wrote:
> 
>> From: "Ries, Paul A (3265-Affiliate)" <Paul.A.Ries at jpl.nasa.gov>
>> Subject: Re: [AstroPy] Enthought Canopy vs. another distribution for Mac?
>> Date: April 30, 2013 10:21:35 AM CDT
>> To: "AstroPy at scipy.org" <AstroPy at scipy.org>
>> 
>> 
>> Eric,
>> 
>> If you're familiar with linux package administration, I recommend using MacPorts ( http://www.macports.org/ ) to install your python.  It's very similar to the apt or yum system used on linux boxes.  It leaves your system python untouched, but lets you install pretty much any free python package out there and allows you to keep everything up to date. (It also works with plenty of other free and astronomically useful software e.g. gcc, gfortran ,editors).  It also provides simple instruction with installation for how to manage which python is used by default.   I dabbled in Enthought and the system python, but I've found Macports to more reliably reproduce the pain-free python experience from linux.
>> 
>> For more on installing with macports:
>> http://astrofrog.github.io/macports-python/
>> 
>> Also, an aside, don't fret much about clobbering CASA.  It will happily stay in its own little python world regardless of what python you're installing.
>> 
>> ----Paul
>> 
>> On Apr 30, 2013, at 7:20 AM, Matt Davis wrote:
>> 
>>> Hi Eric, I generally recommend the Anaconda distro: http://continuum.io/downloads.html It's open source and supports setting up different environments, and it's nicely self contained so it won't mess with anything else you have installed. You can set it up on both Mac and Linux without root.
>>> 
>>> Best,
>>> Matt
>>> 
>>> On Apr 30, 2013, at 10:13 AM, "Eric L. N. Jensen" <ejensen1 at swarthmore.edu>
>>>  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I've gradually been making the switch both to using Python more for my data analysis, and also doing more of my work on a Mac rather than Linux.  So I've decided it's time to get my Mac python distribution(s) in order (there are several of them running around on my machine, from various packages) and start fresh with a new python distro that I'll maintain as my main work environment. 
>>>> 
>>>> The page at http://python4astronomers.github.io/installation/python_install.html recommends Enthought Python as a good place to start, but I find that this has now changed to a different environment called Canopy.  Any opinions on whether I should install Canopy, or choose a different distro?
>>>> 
>>>> A few pieces of information that may be helpful in answering this:
>>>> 
>>>> 1.  I'm running Mac OSX 10.7, 64-bit.
>>>> 2.  I'm comfortable installing/building software from the command line (as root or not).
>>>> 3.  BUT all of my installation/sys-admin experience is with non-python software, and much of it on Linux.  I don't have any experience with managing a python environment, especially with multiple python installations, and I don't want to mess up the system python install (or the internal python installs for other software I have installed, like CASA).  
>>>> 4.  I *do* qualify for the Enthought academic license, so I can use that rather than the free version. 
>>>> 5.  If this goes well, I'd probably like to set up a similar environment on my linux machine as well, though this is relatively low priority if otherwise there's a good Mac-only solution. 
>>>> 
>>>> Thanks in advance for your help with this - let me know if there's other info that would be useful.
>>>> 
>>>> Eric Jensen
>>>> 
>>>> 
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/astropy
>>> 
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> 
> 
> -- 
> Kelle Cruz, PhD ? http://kellecruz.com/
> 917.725.1334 ? Hunter: x16486 ? AMNH: x3404
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130505/70cbc916/attachment.html>

From lee.j.joon at gmail.com  Mon May  6 00:44:35 2013
From: lee.j.joon at gmail.com (Jae-Joon Lee)
Date: Mon, 6 May 2013 13:44:35 +0900
Subject: [AstroPy] ANN: pyregion 1.1.1 (w/ Python 3 support)
Message-ID: <CAG=uJ+nVTVGQjQKJtseXf_0A8=0JOVvbsfEiWcaaN5QQGQS6Dg@mail.gmail.com>

I am pleased to announce the release of pyregion 1.1.1.

[pyregion]

A python module to parse ds9 (and ciao) region files. It also supports
spatial filtering using the regions and displaying them w/ matpltolib.

* `pyregion' is now compatible with python 3.2 and also with astropy.

* To install : pip install pyregion

* documentation : http://leejjoon.github.io/pyregion

* github repo : https://github.com/leejjoon/pyregion


Regards,

-JJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130506/1d6fdbbf/attachment.html>

From aldcroft at head.cfa.harvard.edu  Mon May  6 07:17:23 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Mon, 6 May 2013 07:17:23 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
Message-ID: <CAGsQ-Nt9_3eFmY8tWS5GTHWODwhm3t5pECMjaA2TvbS8EAHdsA@mail.gmail.com>

Hi Kelle,

Moritz Guenther has put together a PR for python4astronomers that does the
Anaconda update and a bit more in terms of simplification.  We're in the
process of reviewing and tweaking the wording a bit, so this should go live
by mid-week.

As for community convergence on a single Python distribution, in a vibrant
open-source community there will always be multiple good solutions, each
catering to somewhat different interests.  The yt Project installation
mentioned by John ZuHone is a perfect example of this.

To me the better way forward is to work on tutorials and tools that make it
easier to manage multiple Python environments.  The key thing is to be able
to configure and switch between environments without much effort, then it
doesn't really matter if you are running Anaconda or EPD or yt or macports.
 The good news is that Anaconda and EPD Canopy are now non-root installs
that just live in a single directory that you can easily blow away with a
single command. The bad news is that neither of those seem to currently
support virtualenv, which would be the obvious and uniform way to manage
your packages.  I'm hoping that the issue with virtualenv will be resolved
soon.

- Tom



On Sun, May 5, 2013 at 11:28 PM, Kelle Cruz <kellecruz at gmail.com> wrote:

> I *hate* that the answer to this question changes so often! Is there any
> hope of it settling down anytime soon?
>
> Is someone planning on updating the python4astronomers install page? I've
> been considering that page the "official" recommendation. Tom? I think the
> only thing that needs to be updated is the box for the impatient?which is
> almost EVERYONE!
>
> kelle
>
>
> On Tue, Apr 30, 2013 at 11:29 AM, Leo Singer <lsinger at caltech.edu> wrote:
>
>> I agree, MacPorts is the way to go. Enthought's 'Free' distribution is
>> crippled; it's 32-bit, which limits speed and array sizes on modern 64-bit
>> machines. MacPorts provides not just Python itself, but hundreds of Python
>> packages, including many that are related to astronomy and other science
>> disciplines.
>>
>> On Apr 30, 2013, at 10:16 AM, astropy-request at scipy.org wrote:
>>
>> *From: *"Ries, Paul A (3265-Affiliate)" <Paul.A.Ries at jpl.nasa.gov>
>> *Subject: **Re: [AstroPy] Enthought Canopy vs. another distribution for
>> Mac?*
>> *Date: *April 30, 2013 10:21:35 AM CDT
>> *To: *"AstroPy at scipy.org" <AstroPy at scipy.org>
>>
>>
>>  Eric,
>>
>>  If you're familiar with linux package administration, I recommend using
>> MacPorts ( http://www.macports.org/ ) to install your python.  It's very
>> similar to the apt or yum system used on linux boxes.  It leaves your
>> system python untouched, but lets you install pretty much any free python
>> package out there and allows you to keep everything up to date. (It also
>> works with plenty of other free and astronomically useful software e.g.
>> gcc, gfortran ,editors).  It also provides simple instruction with
>> installation for how to manage which python is used by default.   I dabbled
>> in Enthought and the system python, but I've found Macports to more
>> reliably reproduce the pain-free python experience from linux.
>>
>>  For more on installing with macports:
>> http://astrofrog.github.io/macports-python/
>>
>>  Also, an aside, don't fret much about clobbering CASA.  It will happily
>> stay in its own little python world regardless of what python you're
>> installing.
>>
>>  ----Paul
>>
>>  On Apr 30, 2013, at 7:20 AM, Matt Davis wrote:
>>
>>  Hi Eric, I generally recommend the Anaconda distro:
>> http://continuum.io/downloads.html It's open source and supports setting
>> up different environments, and it's nicely self contained so it won't mess
>> with anything else you have installed. You can set it up on both Mac and
>> Linux without root.
>>
>>  Best,
>> Matt
>>
>>  On Apr 30, 2013, at 10:13 AM, "Eric L. N. Jensen" <
>> ejensen1 at swarthmore.edu>
>>  wrote:
>>
>> Hi,
>>
>> I've gradually been making the switch both to using Python more for my
>> data analysis, and also doing more of my work on a Mac rather than Linux.
>>  So I've decided it's time to get my Mac python distribution(s) in order
>> (there are several of them running around on my machine, from various
>> packages) and start fresh with a new python distro that I'll maintain as my
>> main work environment.
>>
>> The page at
>> http://python4astronomers.github.io/installation/python_install.htmlrecommends Enthought Python as a good place to start, but I find that this
>> has now changed to a different environment called Canopy.  Any opinions on
>> whether I should install Canopy, or choose a different distro?
>>
>> A few pieces of information that may be helpful in answering this:
>>
>> 1.  I'm running Mac OSX 10.7, 64-bit.
>> 2.  I'm comfortable installing/building software from the command line
>> (as root or not).
>> 3.  BUT all of my installation/sys-admin experience is with non-python
>> software, and much of it on Linux.  I don't have any experience with
>> managing a python environment, especially with multiple python
>> installations, and I don't want to mess up the system python install (or
>> the internal python installs for other software I have installed, like
>> CASA).
>> 4.  I *do* qualify for the Enthought academic license, so I can use that
>> rather than the free version.
>> 5.  If this goes well, I'd probably like to set up a similar environment
>> on my linux machine as well, though this is relatively low priority if
>> otherwise there's a good Mac-only solution.
>>
>> Thanks in advance for your help with this - let me know if there's other
>> info that would be useful.
>>
>> Eric Jensen
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>  _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>
> --
> Kelle Cruz, PhD ? http://kellecruz.com/
> 917.725.1334 ? Hunter: x16486 ? AMNH: x3404
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130506/79de5e4c/attachment.html>

From ejensen1 at swarthmore.edu  Mon May  6 17:22:31 2013
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Mon, 6 May 2013 17:22:31 -0400
Subject: [AstroPy] Importing packages across distributions?
Message-ID: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>

Hi all,

First, thanks for your answers to my previous question about an easy-to-install python distribution - I ended up installing anaconda. 

My next question is most likely a pretty elementary bit of python, but I haven't succeeded in finding a discussion of it: to what extent are packages installed under one distribution's tree importable by another distribution?  I had thought/hoped that after installing anaconda (with its rich collection of auxiliary packages) that I might be able to do the following within CASA (with has its own python installation):

   sys.path.append('/Users/ejensen1/anaconda')

   from astropy import coordinates as coord

but that fails with "No module named astropy".    The situation is similar if I can start up the Mac OS system-distributed python, so it's not just a CASA thing. 

So my specific question is whether this sort of thing is ever possible (simply importing a module from somewhere else in a directory tree), and more generally where to find some documentation / discussion of this issue - all the discussions I've found so far (probably not searching on the right words) imply that importing modules is simply a matter of setting the path correctly, but it's clearly more complicated than that.

Thanks,

Eric






From thomas.robitaille at gmail.com  Mon May  6 17:28:22 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 6 May 2013 23:28:22 +0200
Subject: [AstroPy] Importing packages across distributions?
In-Reply-To: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
References: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
Message-ID: <CAGMHX_1078tYNpSqUQaPdT=wiYVynJYvE6h0SQpL9ZguFg76gA@mail.gmail.com>

Hi Eric,

CASA uses it's own Python installation, which is separate from
Anaconda and other distributions. While it's possible to mess with
PYTHONPATH to make CASA and other Python distributions see the same
packages, it's kind of a hack. Instead, the easiest way (in my
opinion) to install Python packages into CASA is to use the script
I've written and made available here:

https://github.com/astrofrog/casa-python

In fact, the README shows you how to install Astropy into CASA.

Let me know if you have any trouble installing it.

Cheers,
Tom


On 6 May 2013 23:22, Eric L. N. Jensen <ejensen1 at swarthmore.edu> wrote:
> Hi all,
>
> First, thanks for your answers to my previous question about an easy-to-install python distribution - I ended up installing anaconda.
>
> My next question is most likely a pretty elementary bit of python, but I haven't succeeded in finding a discussion of it: to what extent are packages installed under one distribution's tree importable by another distribution?  I had thought/hoped that after installing anaconda (with its rich collection of auxiliary packages) that I might be able to do the following within CASA (with has its own python installation):
>
>    sys.path.append('/Users/ejensen1/anaconda')
>
>    from astropy import coordinates as coord
>
> but that fails with "No module named astropy".    The situation is similar if I can start up the Mac OS system-distributed python, so it's not just a CASA thing.
>
> So my specific question is whether this sort of thing is ever possible (simply importing a module from somewhere else in a directory tree), and more generally where to find some documentation / discussion of this issue - all the discussions I've found so far (probably not searching on the right words) imply that importing modules is simply a matter of setting the path correctly, but it's clearly more complicated than that.
>
> Thanks,
>
> Eric
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From goldbaum at ucolick.org  Mon May  6 17:30:53 2013
From: goldbaum at ucolick.org (Nathan Goldbaum)
Date: Mon, 6 May 2013 14:30:53 -0700
Subject: [AstroPy] Importing packages across distributions?
In-Reply-To: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
References: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
Message-ID: <CAJXewOm93fGy707XghFduCBiKpb6M730oH_NXcEo+-U-iXbUwQ@mail.gmail.com>

Hi Eric,

I think you need to recursively add all the subfolders in the anaconda
folder to your sys.path.  You can also manage all this from the command
line by setting the PYTHONPATH.

I'm not familiar with CASA, but presumably it should be possible to install
it in a way that uses anaconda's python instead of relying on its own, that
way you won't need to worry about this PYTHONPATH mess.  Instructions on
how to build CASA from source are available here:
https://safe.nrao.edu/wiki/bin/view/Main/ScottRankinCasaBuildNotes

Cheers,

Nathan


On Mon, May 6, 2013 at 2:22 PM, Eric L. N. Jensen
<ejensen1 at swarthmore.edu>wrote:

> Hi all,
>
> First, thanks for your answers to my previous question about an
> easy-to-install python distribution - I ended up installing anaconda.
>
> My next question is most likely a pretty elementary bit of python, but I
> haven't succeeded in finding a discussion of it: to what extent are
> packages installed under one distribution's tree importable by another
> distribution?  I had thought/hoped that after installing anaconda (with its
> rich collection of auxiliary packages) that I might be able to do the
> following within CASA (with has its own python installation):
>
>    sys.path.append('/Users/ejensen1/anaconda')
>
>    from astropy import coordinates as coord
>
> but that fails with "No module named astropy".    The situation is similar
> if I can start up the Mac OS system-distributed python, so it's not just a
> CASA thing.
>
> So my specific question is whether this sort of thing is ever possible
> (simply importing a module from somewhere else in a directory tree), and
> more generally where to find some documentation / discussion of this issue
> - all the discussions I've found so far (probably not searching on the
> right words) imply that importing modules is simply a matter of setting the
> path correctly, but it's clearly more complicated than that.
>
> Thanks,
>
> Eric
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130506/c9d672e7/attachment.html>

From jturner at gemini.edu  Mon May  6 17:31:45 2013
From: jturner at gemini.edu (James Turner)
Date: Mon, 6 May 2013 17:31:45 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
Message-ID: <51882141.3010301@gemini.edu>

Yeah, so we and STScI are also close to releasing a beta of Ureka,
with all the usual Python stuff like SciPy, Matplotlib etc. as well
as IRAF 2.16 and its external packages. That's what we'll be
recommending to our users. It's for Linux and Apple and doesn't
normally require root privileges. Sorry to add to your near-term
options :-).

Cheers,

James.

PS. No, Anaconda wasn't around when we started this.


On 05/05/13 23:28, Kelle Cruz wrote:
> I *hate* that the answer to this question changes so often! Is there any hope of
> it settling down anytime soon?
>
> Is someone planning on updating the python4astronomers install page? I've been
> considering that page the "official" recommendation. Tom? I think the only thing
> that needs to be updated is the box for the impatient?which is almost EVERYONE!
>
> kelle
>
>
> On Tue, Apr 30, 2013 at 11:29 AM, Leo Singer <lsinger at caltech.edu
> <mailto:lsinger at caltech.edu>> wrote:
>
>     I agree, MacPorts is the way to go. Enthought's 'Free' distribution is
>     crippled; it's 32-bit, which limits speed and array sizes on modern 64-bit
>     machines. MacPorts provides not just Python itself, but hundreds of Python
>     packages, including many that are related to astronomy and other science
>     disciplines.
>
>     On Apr 30, 2013, at 10:16 AM, astropy-request at scipy.org
>     <mailto:astropy-request at scipy.org> wrote:
>
>>     *From: *"Ries, Paul A (3265-Affiliate)" <Paul.A.Ries at jpl.nasa.gov
>>     <mailto:Paul.A.Ries at jpl.nasa.gov>>
>>     *Subject: **Re: [AstroPy] Enthought Canopy vs. another distribution for Mac?*
>>     *Date: *April 30, 2013 10:21:35 AM CDT
>>     *To: *"AstroPy at scipy.org <mailto:AstroPy at scipy.org>" <AstroPy at scipy.org
>>     <mailto:AstroPy at scipy.org>>
>>
>>
>>     Eric,
>>
>>     If you're familiar with linux package administration, I recommend using
>>     MacPorts ( http://www.macports.org/ ) to install your python.  It's very
>>     similar to the apt or yum system used on linux boxes.  It leaves your
>>     system python untouched, but lets you install pretty much any free python
>>     package out there and allows you to keep everything up to date. (It also
>>     works with plenty of other free and astronomically useful software e.g.
>>     gcc, gfortran ,editors).  It also provides simple instruction with
>>     installation for how to manage which python is used by default.   I
>>     dabbled in Enthought and the system python, but I've found Macports to
>>     more reliably reproduce the pain-free python experience from linux.
>>
>>     For more on installing with macports:
>>     http://astrofrog.github.io/macports-python/
>>
>>     Also, an aside, don't fret much about clobbering CASA.  It will happily
>>     stay in its own little python world regardless of what python you're
>>     installing.
>>
>>     ----Paul
>>
>>     On Apr 30, 2013, at 7:20 AM, Matt Davis wrote:
>>
>>>     Hi Eric, I generally recommend the Anaconda distro:
>>>     http://continuum.io/downloads.html It's open source and supports setting
>>>     up different environments, and it's nicely self contained so it won't
>>>     mess with anything else you have installed. You can set it up on both Mac
>>>     and Linux without root.
>>>
>>>     Best,
>>>     Matt
>>>
>>>     On Apr 30, 2013, at 10:13 AM, "Eric L. N. Jensen"
>>>     <ejensen1 at swarthmore.edu <mailto:ejensen1 at swarthmore.edu>>
>>>      wrote:
>>>
>>>>     Hi,
>>>>
>>>>     I've gradually been making the switch both to using Python more for my
>>>>     data analysis, and also doing more of my work on a Mac rather than
>>>>     Linux.  So I've decided it's time to get my Mac python distribution(s)
>>>>     in order (there are several of them running around on my machine, from
>>>>     various packages) and start fresh with a new python distro that I'll
>>>>     maintain as my main work environment.
>>>>
>>>>     The page at
>>>>     http://python4astronomers.github.io/installation/python_install.html
>>>>     recommends Enthought Python as a good place to start, but I find that
>>>>     this has now changed to a different environment called Canopy.  Any
>>>>     opinions on whether I should install Canopy, or choose a different distro?
>>>>
>>>>     A few pieces of information that may be helpful in answering this:
>>>>
>>>>     1.  I'm running Mac OSX 10.7, 64-bit.
>>>>     2.  I'm comfortable installing/building software from the command line
>>>>     (as root or not).
>>>>     3.  BUT all of my installation/sys-admin experience is with non-python
>>>>     software, and much of it on Linux.  I don't have any experience with
>>>>     managing a python environment, especially with multiple python
>>>>     installations, and I don't want to mess up the system python install (or
>>>>     the internal python installs for other software I have installed, like
>>>>     CASA).
>>>>     4.  I *do* qualify for the Enthought academic license, so I can use that
>>>>     rather than the free version.
>>>>     5.  If this goes well, I'd probably like to set up a similar environment
>>>>     on my linux machine as well, though this is relatively low priority if
>>>>     otherwise there's a good Mac-only solution.
>>>>
>>>>     Thanks in advance for your help with this - let me know if there's other
>>>>     info that would be useful.
>>>>
>>>>     Eric Jensen
>>>>
>>>>
>>>>     _______________________________________________
>>>>     AstroPy mailing list
>>>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>>     http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>     _______________________________________________
>>>     AstroPy mailing list
>>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>>     http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>>     _______________________________________________
>>     AstroPy mailing list
>>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>     http://mail.scipy.org/mailman/listinfo/astropy
>
>
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
>
> --
> Kelle Cruz, PhD ? http://kellecruz.com/
> 917.725.1334 ? Hunter: x16486 ? AMNH: x3404
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From ejensen1 at swarthmore.edu  Mon May  6 17:43:38 2013
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Mon, 6 May 2013 17:43:38 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <51882141.3010301@gemini.edu>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
	<51882141.3010301@gemini.edu>
Message-ID: <594C66BF-0744-4030-8FF7-CDEBD27F6342@swarthmore.edu>

Thanks, James - it would be great to have an easy-to-install IRAF/pyraf distribution with an up-to-date version of IRAF.  The one included in the current pyraf distribution is pretty ancient.

I hope you'll post an announcement here when it's ready to go. 

Eric

On May 6, 2013, at 5:31 PM, James Turner wrote:

> Yeah, so we and STScI are also close to releasing a beta of Ureka,
> with all the usual Python stuff like SciPy, Matplotlib etc. as well
> as IRAF 2.16 and its external packages. That's what we'll be
> recommending to our users. It's for Linux and Apple and doesn't
> normally require root privileges. Sorry to add to your near-term
> options :-).
> 
> Cheers,
> 
> James.
> 
> PS. No, Anaconda wasn't around when we started this.



From jturner at gemini.edu  Mon May  6 17:47:22 2013
From: jturner at gemini.edu (James Turner)
Date: Mon, 6 May 2013 17:47:22 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <594C66BF-0744-4030-8FF7-CDEBD27F6342@swarthmore.edu>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
	<51882141.3010301@gemini.edu>
	<594C66BF-0744-4030-8FF7-CDEBD27F6342@swarthmore.edu>
Message-ID: <518824EA.1010603@gemini.edu>

> I hope you'll post an announcement here when it's ready to go.

Certainly. I hope STScI doesn't mind me having pre-empted it
slightly but the project is no secret and it seemed useful to
mention it in this discussion.

Cheers,

James.



From deil.christoph at googlemail.com  Mon May  6 18:09:49 2013
From: deil.christoph at googlemail.com (Christoph Deil)
Date: Tue, 7 May 2013 00:09:49 +0200
Subject: [AstroPy] Importing packages across distributions?
In-Reply-To: <CAGMHX_1078tYNpSqUQaPdT=wiYVynJYvE6h0SQpL9ZguFg76gA@mail.gmail.com>
References: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
	<CAGMHX_1078tYNpSqUQaPdT=wiYVynJYvE6h0SQpL9ZguFg76gA@mail.gmail.com>
Message-ID: <F957A6A4-B623-46DA-A58F-70B471D74E33@gmail.com>

Hi,

I've run into a similar problem ? I wanted to install astropy into the Python that comes with the
Chandra [1] and Fermi [2] analysis tools to be able to use astropy and their tools from the same script.
[1] http://cxc.harvard.edu/ciao/index.html
[2] http://fermi.gsfc.nasa.gov/ssc/data/analysis/software/

Sometimes it is possible to make this work, but most of the time (at least on Mac) the astropy build fails.
The problem is that these analysis packages are basically impossible to build from source (at least on Mac),
so one has to get the binary distribution and then some incompatibility with the compiler or other libraries
on the user machine occurs when trying to build astropy.

I guess there's nothing that can be done to improve this situation from the astropy side,
except maybe share hacks how to make it work?
Or if someone knows people maintaining those big astro analysis packages that come with their
own Python to ask them to test if building astropy works with their Python on common platforms?

Christoph

On May 6, 2013, at 11:28 PM, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:

> Hi Eric,
> 
> CASA uses it's own Python installation, which is separate from
> Anaconda and other distributions. While it's possible to mess with
> PYTHONPATH to make CASA and other Python distributions see the same
> packages, it's kind of a hack. Instead, the easiest way (in my
> opinion) to install Python packages into CASA is to use the script
> I've written and made available here:
> 
> https://github.com/astrofrog/casa-python
> 
> In fact, the README shows you how to install Astropy into CASA.
> 
> Let me know if you have any trouble installing it.
> 
> Cheers,
> Tom
> 
> 
> On 6 May 2013 23:22, Eric L. N. Jensen <ejensen1 at swarthmore.edu> wrote:
>> Hi all,
>> 
>> First, thanks for your answers to my previous question about an easy-to-install python distribution - I ended up installing anaconda.
>> 
>> My next question is most likely a pretty elementary bit of python, but I haven't succeeded in finding a discussion of it: to what extent are packages installed under one distribution's tree importable by another distribution?  I had thought/hoped that after installing anaconda (with its rich collection of auxiliary packages) that I might be able to do the following within CASA (with has its own python installation):
>> 
>>   sys.path.append('/Users/ejensen1/anaconda')
>> 
>>   from astropy import coordinates as coord
>> 
>> but that fails with "No module named astropy".    The situation is similar if I can start up the Mac OS system-distributed python, so it's not just a CASA thing.
>> 
>> So my specific question is whether this sort of thing is ever possible (simply importing a module from somewhere else in a directory tree), and more generally where to find some documentation / discussion of this issue - all the discussions I've found so far (probably not searching on the right words) imply that importing modules is simply a matter of setting the path correctly, but it's clearly more complicated than that.
>> 
>> Thanks,
>> 
>> Eric
>> 
>> 
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From thomas.robitaille at gmail.com  Mon May  6 18:35:37 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 7 May 2013 00:35:37 +0200
Subject: [AstroPy] Importing packages across distributions?
In-Reply-To: <CAJXewOm93fGy707XghFduCBiKpb6M730oH_NXcEo+-U-iXbUwQ@mail.gmail.com>
References: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
	<CAJXewOm93fGy707XghFduCBiKpb6M730oH_NXcEo+-U-iXbUwQ@mail.gmail.com>
Message-ID: <CAGMHX_2VNpWVJqJ0ZSqTsc5CjMrprm+LwQNobvmd3BhHUKr47w@mail.gmail.com>

On 6 May 2013 23:30, Nathan Goldbaum <goldbaum at ucolick.org> wrote:
> Hi Eric,
>
> I think you need to recursively add all the subfolders in the anaconda
> folder to your sys.path.  You can also manage all this from the command line
> by setting the PYTHONPATH.

I strongly recommend against this - see my previous email. For a
start, CASA and Anaconda may be using different Python versions (in
fact they are) and some of the Anaconda packages may conflict with
CASA.

The correct way to do it is to install the packages directly into CASA:

https://github.com/astrofrog/casa-python

Eric confirmed off-list that this worked.

Cheers,
Tom

>
> I'm not familiar with CASA, but presumably it should be possible to install
> it in a way that uses anaconda's python instead of relying on its own, that
> way you won't need to worry about this PYTHONPATH mess.  Instructions on how
> to build CASA from source are available here:
> https://safe.nrao.edu/wiki/bin/view/Main/ScottRankinCasaBuildNotes
>
> Cheers,
>
> Nathan
>
>
> On Mon, May 6, 2013 at 2:22 PM, Eric L. N. Jensen <ejensen1 at swarthmore.edu>
> wrote:
>>
>> Hi all,
>>
>> First, thanks for your answers to my previous question about an
>> easy-to-install python distribution - I ended up installing anaconda.
>>
>> My next question is most likely a pretty elementary bit of python, but I
>> haven't succeeded in finding a discussion of it: to what extent are packages
>> installed under one distribution's tree importable by another distribution?
>> I had thought/hoped that after installing anaconda (with its rich collection
>> of auxiliary packages) that I might be able to do the following within CASA
>> (with has its own python installation):
>>
>>    sys.path.append('/Users/ejensen1/anaconda')
>>
>>    from astropy import coordinates as coord
>>
>> but that fails with "No module named astropy".    The situation is similar
>> if I can start up the Mac OS system-distributed python, so it's not just a
>> CASA thing.
>>
>> So my specific question is whether this sort of thing is ever possible
>> (simply importing a module from somewhere else in a directory tree), and
>> more generally where to find some documentation / discussion of this issue -
>> all the discussions I've found so far (probably not searching on the right
>> words) imply that importing modules is simply a matter of setting the path
>> correctly, but it's clearly more complicated than that.
>>
>> Thanks,
>>
>> Eric
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From aldcroft at head.cfa.harvard.edu  Mon May  6 18:38:41 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Mon, 6 May 2013 18:38:41 -0400
Subject: [AstroPy] Importing packages across distributions?
In-Reply-To: <F957A6A4-B623-46DA-A58F-70B471D74E33@gmail.com>
References: <A457869F-6420-405F-B614-8A48F6F5BD86@swarthmore.edu>
	<CAGMHX_1078tYNpSqUQaPdT=wiYVynJYvE6h0SQpL9ZguFg76gA@mail.gmail.com>
	<F957A6A4-B623-46DA-A58F-70B471D74E33@gmail.com>
Message-ID: <CAGsQ-NtcSg9g7MiKUsjVQ+FiaCgQ6wiaef_quy2r2hf0FdK9Cw@mail.gmail.com>

On Mon, May 6, 2013 at 6:09 PM, Christoph Deil <
deil.christoph at googlemail.com> wrote:

> Hi,
>
> I've run into a similar problem ? I wanted to install astropy into the
> Python that comes with the
> Chandra [1] and Fermi [2] analysis tools to be able to use astropy and
> their tools from the same script.
> [1] http://cxc.harvard.edu/ciao/index.html
> [2] http://fermi.gsfc.nasa.gov/ssc/data/analysis/software/
>
> Sometimes it is possible to make this work, but most of the time (at least
> on Mac) the astropy build fails.
> The problem is that these analysis packages are basically impossible to
> build from source (at least on Mac),
> so one has to get the binary distribution and then some incompatibility
> with the compiler or other libraries
> on the user machine occurs when trying to build astropy.
>

Are you using the "ciaorun" prefix, as in "ciaorun python setup.py install"
?  This probably won't solve all compiler/library issues, but it's a good
start.


> I guess there's nothing that can be done to improve this situation from
> the astropy side,
> except maybe share hacks how to make it work?
> Or if someone knows people maintaining those big astro analysis packages
> that come with their
> own Python to ask them to test if building astropy works with their Python
> on common platforms?
>

For CIAO at least a good strategy is putting in helpdesk tickets.  That
gives the CIAO team an idea of how people are using CIAO Python and what
needs they should address.  I certainly think that a thread aimed at
providing guidance on building external packages within CIAO Python would
be valuable.

- Tom


>
> Christoph
>
> On May 6, 2013, at 11:28 PM, Thomas Robitaille <
> thomas.robitaille at gmail.com> wrote:
>
> > Hi Eric,
> >
> > CASA uses it's own Python installation, which is separate from
> > Anaconda and other distributions. While it's possible to mess with
> > PYTHONPATH to make CASA and other Python distributions see the same
> > packages, it's kind of a hack. Instead, the easiest way (in my
> > opinion) to install Python packages into CASA is to use the script
> > I've written and made available here:
> >
> > https://github.com/astrofrog/casa-python
> >
> > In fact, the README shows you how to install Astropy into CASA.
> >
> > Let me know if you have any trouble installing it.
> >
> > Cheers,
> > Tom
> >
> >
> > On 6 May 2013 23:22, Eric L. N. Jensen <ejensen1 at swarthmore.edu> wrote:
> >> Hi all,
> >>
> >> First, thanks for your answers to my previous question about an
> easy-to-install python distribution - I ended up installing anaconda.
> >>
> >> My next question is most likely a pretty elementary bit of python, but
> I haven't succeeded in finding a discussion of it: to what extent are
> packages installed under one distribution's tree importable by another
> distribution?  I had thought/hoped that after installing anaconda (with its
> rich collection of auxiliary packages) that I might be able to do the
> following within CASA (with has its own python installation):
> >>
> >>   sys.path.append('/Users/ejensen1/anaconda')
> >>
> >>   from astropy import coordinates as coord
> >>
> >> but that fails with "No module named astropy".    The situation is
> similar if I can start up the Mac OS system-distributed python, so it's not
> just a CASA thing.
> >>
> >> So my specific question is whether this sort of thing is ever possible
> (simply importing a module from somewhere else in a directory tree), and
> more generally where to find some documentation / discussion of this issue
> - all the discussions I've found so far (probably not searching on the
> right words) imply that importing modules is simply a matter of setting the
> path correctly, but it's clearly more complicated than that.
> >>
> >> Thanks,
> >>
> >> Eric
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/astropy
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130506/bc421633/attachment.html>

From sransom at nrao.edu  Tue May  7 06:34:11 2013
From: sransom at nrao.edu (Scott Ransom)
Date: Tue, 07 May 2013 12:34:11 +0200
Subject: [AstroPy] message from SOFA chair
Message-ID: <5188D8A3.9050707@nrao.edu>

Hi All,

Catherine has asked me, as a new SOFA board member and astropy-list 
member, to send this to the list.

Scott

--------------

          To all participations in the astropy e-mail forum

Our records show that various emails to me as Chair of the IAU SOFA
Board did not receive a reply.  This happened for reasons outside my
control and I am very sorry.

The fault lies with the spam filtering arrangements at my institution,
which have to comply with the strict IT security policies that all UK
Government establishments operate.  All automatic spam filters suffer to
some degree from false positives, and the actual failure in this case
was in the manual monitoring that was supposed to detect such cases.
Measures have since been taken to make this less likely in the future.

On the subject of the SOFA license conditions, our Board member Patrick
Wallace is continuing discussions he had on this topic last year, which
resulted in changes to the license that enabled the Debian release to
proceed.  Recent emails, which unfortunately were delayed by the spam
filter problems, show that further discussion is needed, and Patrick is
now in touch with Perry Greenfield, STScI Science Software Branch lead.
The nub of the problem is that SOFA software has to address two
conflicting requirements: (i) the insistence by free software groups
that users should not be constrained in any way and (ii) the need to
prevent "counterfeit" versions coming into circulation.  The second
point is vital because SOFA software represents IAU standards and indeed
is cited in other standards such as IERS Conventions.


Catherine
Chair, IAU SOFA Board
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
HM Nautical Almanac Office
United Kingdom Hydrographic Office
Admiralty Way
Taunton TA1 2DN
Catherine.Hohenkerk at UKHO.gov.uk
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989


From jslavin at cfa.harvard.edu  Tue May  7 09:06:20 2013
From: jslavin at cfa.harvard.edu (Jonathan Slavin)
Date: Tue, 07 May 2013 09:06:20 -0400
Subject: [AstroPy] Importing packages across distributions?
Message-ID: <1367931980.7513.4.camel@shevek>

Hi Christoph,

I don't know about the Fermi software, but you can install sherpa (the
CIAO analysis package) as a standalone python package.  I've used it
that way (though I didn't install it).  See
http://cxc.cfa.harvard.edu/contrib/sherpa/

Regards,
Jon

> Hi,
> 
> I've run into a similar problem ? I wanted to install astropy into the
> Python that comes with the
> Chandra [1] and Fermi [2] analysis tools to be able to use astropy and
> their tools from the same script.
> [1] http://cxc.harvard.edu/ciao/index.html
> [2] http://fermi.gsfc.nasa.gov/ssc/data/analysis/software/
> 
> Sometimes it is possible to make this work, but most of the time (at
> least on Mac) the astropy build fails.
> The problem is that these analysis packages are basically impossible
> to build from source (at least on Mac),
> so one has to get the binary distribution and then some
> incompatibility with the compiler or other libraries
> on the user machine occurs when trying to build astropy.
> 
> I guess there's nothing that can be done to improve this situation
> from the astropy side,
> except maybe share hacks how to make it work?
> Or if someone knows people maintaining those big astro analysis
> packages that come with their
> own Python to ask them to test if building astropy works with their
> Python on common platforms?
> 
> Christoph
-- 
______________________________________________________________
Jonathan D. Slavin              Harvard-Smithsonian CfA
jslavin at cfa.harvard.edu         60 Garden Street, MS 83
phone: (617) 496-7981           Cambridge, MA 02138-1516
 cell: (781) 363-0035           USA
______________________________________________________________



From mjuric at lsst.org  Tue May  7 09:37:50 2013
From: mjuric at lsst.org (Mario Juric)
Date: Tue, 07 May 2013 09:37:50 -0400
Subject: [AstroPy] message from SOFA chair
In-Reply-To: <5188D8A3.9050707@nrao.edu>
References: <5188D8A3.9050707@nrao.edu>
Message-ID: <518903AE.6030701@lsst.org>

On 5/7/13 6:34 , Scott Ransom wrote:
> Hi All,
> 
> Catherine has asked me, as a new SOFA board member and astropy-list 
> member, to send this to the list.
> 

...[snip]...

> The nub of the problem is that SOFA software has to address two
> conflicting requirements: (i) the insistence by free software groups
> that users should not be constrained in any way and (ii) the need to
> prevent "counterfeit" versions coming into circulation.  The second
> point is vital because SOFA software represents IAU standards and indeed
> is cited in other standards such as IERS Conventions.
> 

Dear Scott,
	I'm happy to hear about the feedback! Regarding the second concern, I
think the GPL explicitly allows such restrictions:

====
7. Additional Terms.

... snip ...

Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders
of that material) supplement the terms of this License with terms:

... snip ...

c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or


(http://www.gnu.org/licenses/gpl.html)
====

If these are the primary concerns, a 3-clause BSD with a requirement to
rename any derivatives may satisfy the SOFA board as well as the free
software communities.

Cheers,
-- 
Mario Juric,
Data Mgmt. Project Scientist, Large Synoptic Survey Telescope
Web   :  http://www.cfa.harvard.edu/~mjuric/
Phone :  +1 617 744 9003       PGP: ~mjuric/crypto/public.key


From tim.jenness at gmail.com  Tue May  7 10:45:51 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Tue, 7 May 2013 07:45:51 -0700
Subject: [AstroPy] message from SOFA chair
In-Reply-To: <5188D8A3.9050707@nrao.edu>
References: <5188D8A3.9050707@nrao.edu>
Message-ID: <CA+G92Rf+Tq3ten9phO-r+3btm8ekEhqieooFB7GJ5xw+85cGJw@mail.gmail.com>

Thanks.


On Tue, May 7, 2013 at 3:34 AM, Scott Ransom <sransom at nrao.edu> wrote:

>
> On the subject of the SOFA license conditions, our Board member Patrick
> Wallace is continuing discussions he had on this topic last year, which
> resulted in changes to the license that enabled the Debian release to
> proceed.  Recent emails, which unfortunately were delayed by the spam
> filter problems, show that further discussion is needed, and Patrick is
> now in touch with Perry Greenfield, STScI Science Software Branch lead.
> The nub of the problem is that SOFA software has to address two
> conflicting requirements: (i) the insistence by free software groups
> that users should not be constrained in any way and (ii) the need to
> prevent "counterfeit" versions coming into circulation.  The second
> point is vital because SOFA software represents IAU standards and indeed
> is cited in other standards such as IERS Conventions.
>
>
>
Regarding the counterfeit argument, isn't this very similar to encryption
libraries where you want to make sure that you are using the official
library and not one you found on the internet that happens to have a back
door? OpenSSL and other libraries deal with this. People are far more
concerned about using the proper OpenSSL than using SOFA but the underlying
principal is the same. OpenSSL has a very straightforward licence (
http://www.openssl.org/source/license.html) which has clearly been approved
for distribution.

-- 
Tim Jenness
CCAT Software Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130507/6e9c7079/attachment.html>

From wkerzendorf at gmail.com  Tue May  7 11:15:40 2013
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Tue, 7 May 2013 11:15:40 -0400
Subject: [AstroPy] message from SOFA chair
In-Reply-To: <CA+G92Rf+Tq3ten9phO-r+3btm8ekEhqieooFB7GJ5xw+85cGJw@mail.gmail.com>
References: <5188D8A3.9050707@nrao.edu>
	<CA+G92Rf+Tq3ten9phO-r+3btm8ekEhqieooFB7GJ5xw+85cGJw@mail.gmail.com>
Message-ID: <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com>

I think what Mario and Tim are proposing is very good as it would alleviate the problems mentioned by Catherine. To speed up the process, we should propose a license text and they could then see if that meets their criteria (make it as hard as possible for them to delay or refuse). 

Cheers
    Wolfgang
On 2013-05-07, at 10:45 AM, Tim Jenness <tim.jenness at gmail.com> wrote:

> Thanks.
> 
> 
> On Tue, May 7, 2013 at 3:34 AM, Scott Ransom <sransom at nrao.edu> wrote:
> 
> On the subject of the SOFA license conditions, our Board member Patrick
> Wallace is continuing discussions he had on this topic last year, which
> resulted in changes to the license that enabled the Debian release to
> proceed.  Recent emails, which unfortunately were delayed by the spam
> filter problems, show that further discussion is needed, and Patrick is
> now in touch with Perry Greenfield, STScI Science Software Branch lead.
> The nub of the problem is that SOFA software has to address two
> conflicting requirements: (i) the insistence by free software groups
> that users should not be constrained in any way and (ii) the need to
> prevent "counterfeit" versions coming into circulation.  The second
> point is vital because SOFA software represents IAU standards and indeed
> is cited in other standards such as IERS Conventions.
> 
> 
> 
> Regarding the counterfeit argument, isn't this very similar to encryption libraries where you want to make sure that you are using the official library and not one you found on the internet that happens to have a back door? OpenSSL and other libraries deal with this. People are far more concerned about using the proper OpenSSL than using SOFA but the underlying principal is the same. OpenSSL has a very straightforward licence (http://www.openssl.org/source/license.html) which has clearly been approved for distribution.
> 
> -- 
> Tim Jenness
> CCAT Software Manager 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130507/4ddda8e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20130507/4ddda8e1/attachment.bin>

From thomas.robitaille at gmail.com  Tue May  7 12:27:12 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 7 May 2013 18:27:12 +0200
Subject: [AstroPy] message from SOFA chair
In-Reply-To: <43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com>
References: <5188D8A3.9050707@nrao.edu>
	<CA+G92Rf+Tq3ten9phO-r+3btm8ekEhqieooFB7GJ5xw+85cGJw@mail.gmail.com>
	<43A19EA6-232C-43E1-8B59-26D360085E21@gmail.com>
Message-ID: <CAGMHX_1fExuba2GjFFEXLongJpyM7FZVX98Hbdx+bt4ozZ7Z2g@mail.gmail.com>

Just for information, we are currently working towards a solution
off-list with the SOFA board, and will inform the list once things
have been settled. So no need to propose a license text at this stage.

Tom

On 7 May 2013 17:15, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:
> I think what Mario and Tim are proposing is very good as it would alleviate
> the problems mentioned by Catherine. To speed up the process, we should
> propose a license text and they could then see if that meets their criteria
> (make it as hard as possible for them to delay or refuse).
>
> Cheers
>     Wolfgang
> On 2013-05-07, at 10:45 AM, Tim Jenness <tim.jenness at gmail.com> wrote:
>
> Thanks.
>
>
> On Tue, May 7, 2013 at 3:34 AM, Scott Ransom <sransom at nrao.edu> wrote:
>>
>>
>> On the subject of the SOFA license conditions, our Board member Patrick
>> Wallace is continuing discussions he had on this topic last year, which
>> resulted in changes to the license that enabled the Debian release to
>> proceed.  Recent emails, which unfortunately were delayed by the spam
>> filter problems, show that further discussion is needed, and Patrick is
>> now in touch with Perry Greenfield, STScI Science Software Branch lead.
>> The nub of the problem is that SOFA software has to address two
>> conflicting requirements: (i) the insistence by free software groups
>> that users should not be constrained in any way and (ii) the need to
>> prevent "counterfeit" versions coming into circulation.  The second
>> point is vital because SOFA software represents IAU standards and indeed
>> is cited in other standards such as IERS Conventions.
>>
>>
>
> Regarding the counterfeit argument, isn't this very similar to encryption
> libraries where you want to make sure that you are using the official
> library and not one you found on the internet that happens to have a back
> door? OpenSSL and other libraries deal with this. People are far more
> concerned about using the proper OpenSSL than using SOFA but the underlying
> principal is the same. OpenSSL has a very straightforward licence
> (http://www.openssl.org/source/license.html) which has clearly been approved
> for distribution.
>
> --
> Tim Jenness
> CCAT Software Manager
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From embray at stsci.edu  Tue May  7 12:38:02 2013
From: embray at stsci.edu (Erik Bray)
Date: Tue, 7 May 2013 12:38:02 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <518824EA.1010603@gemini.edu>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
	<51882141.3010301@gemini.edu>
	<594C66BF-0744-4030-8FF7-CDEBD27F6342@swarthmore.edu>
	<518824EA.1010603@gemini.edu>
Message-ID: <51892DEA.1000704@stsci.edu>

On 05/06/2013 05:47 PM, James Turner wrote:
>> I hope you'll post an announcement here when it's ready to go.
>
> Certainly. I hope STScI doesn't mind me having pre-empted it
> slightly but the project is no secret and it seemed useful to
> mention it in this discussion.

Indeed, it may add to the "options" but it is unique for its inclusion of IRAF 
and other such Astronomy-specific features.

> Cheers,
>
> James.
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



From ejensen1 at swarthmore.edu  Wed May  8 15:58:49 2013
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Wed, 8 May 2013 15:58:49 -0400
Subject: [AstroPy] Reprojecting each slice in a data cube based on another
	cube's WCS?
Message-ID: <A00F693E-04BD-4C4D-9BF7-CA0BFE48D89E@swarthmore.edu>

Hi all,

I'm working on a comparison of disk models to some ALMA synthesis imaging data, and in order to be able to compare models to data on a pixel-by-pixel basis, I'd like to be able to reproject each of the planes in a model data cube, based on the world coordinate system (WCS) information in the header of the observed data. I thought I might be able to do this with the python wrapper to Montage (using mProject), but it doesn't appear that mProject will handle 3D data (though I have posted a query to the Montage users' list as well to see if I'm missing something there). 

My files are FITS files with NAXIS = 3, where the first two axes are RA and Dec and the third axis is frequency or velocity, i.e. each slice of the third dimension is a 2-D image at a different frequency. 

The CRVAL/CDELT/CRPIX values of the third axis are already identical in both models and data, so no reprojection/resampling along the third axis is necessary - essentially I'm looking for an efficient way to spatially re-project each 2D image plane -  ideally without disassembling all the slices, reprojecting them individually, and reassembling them into a single file. 

I'm sure that python has various lower-level interpolation/resampling algorithms that I can use if necessary, but I'm hoping not to have to do the FITS header keyword parsing / recalculating / reprojecting work myself if this is already possible with existing high-level tools.  (The field of view is small, so it's really just a linear resampling problem, no complicated wide-field projection issues.)

Thanks in advance for your help with this,

Eric


From tim.jenness at gmail.com  Wed May  8 16:20:04 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 8 May 2013 13:20:04 -0700
Subject: [AstroPy] Reprojecting each slice in a data cube based on
 another cube's WCS?
In-Reply-To: <A00F693E-04BD-4C4D-9BF7-CA0BFE48D89E@swarthmore.edu>
References: <A00F693E-04BD-4C4D-9BF7-CA0BFE48D89E@swarthmore.edu>
Message-ID: <CA+G92ReHOMBQYzuXbZeN2txu53=p7TTZa6eMxYD40Ytw1vM4gw@mail.gmail.com>

Not an astropy answer but the Starlink wcsalign command (part of kappa)
does this. You just give it your reference cube and the cubes you want
resampled and it works it all out.

http://www.starlink.ac.uk

Specifically http://www.starlink.ac.uk/docs/sun95.htx/node427.html

This is all done using the AST library so you can do it at a bit of a lower
level using pyast.

-- 
Tim Jenness


On Wed, May 8, 2013 at 12:58 PM, Eric L. N. Jensen
<ejensen1 at swarthmore.edu>wrote:

> Hi all,
>
> I'm working on a comparison of disk models to some ALMA synthesis imaging
> data, and in order to be able to compare models to data on a pixel-by-pixel
> basis, I'd like to be able to reproject each of the planes in a model data
> cube, based on the world coordinate system (WCS) information in the header
> of the observed data. I thought I might be able to do this with the python
> wrapper to Montage (using mProject), but it doesn't appear that mProject
> will handle 3D data (though I have posted a query to the Montage users'
> list as well to see if I'm missing something there).
>
> My files are FITS files with NAXIS = 3, where the first two axes are RA
> and Dec and the third axis is frequency or velocity, i.e. each slice of the
> third dimension is a 2-D image at a different frequency.
>
> The CRVAL/CDELT/CRPIX values of the third axis are already identical in
> both models and data, so no reprojection/resampling along the third axis is
> necessary - essentially I'm looking for an efficient way to spatially
> re-project each 2D image plane -  ideally without disassembling all the
> slices, reprojecting them individually, and reassembling them into a single
> file.
>
> I'm sure that python has various lower-level interpolation/resampling
> algorithms that I can use if necessary, but I'm hoping not to have to do
> the FITS header keyword parsing / recalculating / reprojecting work myself
> if this is already possible with existing high-level tools.  (The field of
> view is small, so it's really just a linear resampling problem, no
> complicated wide-field projection issues.)
>
> Thanks in advance for your help with this,
>
> Eric
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130508/55d6f4f4/attachment.html>

From aldcroft at head.cfa.harvard.edu  Thu May  9 12:10:54 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Thu, 9 May 2013 12:10:54 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
	<B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>
	<CAApiRV4oPTr1fnCR85Tk8rBaJQzLdae7gDmfOcRZ+R1f0U6KYA@mail.gmail.com>
Message-ID: <CAGsQ-Nt50VkSUnG4kUvF2KqFG3WQuAE0T8jpCNW_NEYwjccTvQ@mail.gmail.com>

On Sun, May 5, 2013 at 11:28 PM, Kelle Cruz <kellecruz at gmail.com> wrote:

> I *hate* that the answer to this question changes so often! Is there any
> hope of it settling down anytime soon?
>
> Is someone planning on updating the python4astronomers install page? I've
> been considering that page the "official" recommendation. Tom? I think the
> only thing that needs to be updated is the box for the impatient?which is
> almost EVERYONE!
>

Moritz Guenther and I have made an update to the Python for Astronomers
site.  It now provides instructions for getting started with Anaconda and
greatly simplifies the overall layout and flow for installation.  Please
see:

  http://python4astronomers.github.io/installation/python_install.html

Cheers,
Tom & Moritz



>
> kelle
>
>
> On Tue, Apr 30, 2013 at 11:29 AM, Leo Singer <lsinger at caltech.edu> wrote:
>
>> I agree, MacPorts is the way to go. Enthought's 'Free' distribution is
>> crippled; it's 32-bit, which limits speed and array sizes on modern 64-bit
>> machines. MacPorts provides not just Python itself, but hundreds of Python
>> packages, including many that are related to astronomy and other science
>> disciplines.
>>
>> On Apr 30, 2013, at 10:16 AM, astropy-request at scipy.org wrote:
>>
>> *From: *"Ries, Paul A (3265-Affiliate)" <Paul.A.Ries at jpl.nasa.gov>
>> *Subject: **Re: [AstroPy] Enthought Canopy vs. another distribution for
>> Mac?*
>> *Date: *April 30, 2013 10:21:35 AM CDT
>> *To: *"AstroPy at scipy.org" <AstroPy at scipy.org>
>>
>>
>>  Eric,
>>
>>  If you're familiar with linux package administration, I recommend using
>> MacPorts ( http://www.macports.org/ ) to install your python.  It's very
>> similar to the apt or yum system used on linux boxes.  It leaves your
>> system python untouched, but lets you install pretty much any free python
>> package out there and allows you to keep everything up to date. (It also
>> works with plenty of other free and astronomically useful software e.g.
>> gcc, gfortran ,editors).  It also provides simple instruction with
>> installation for how to manage which python is used by default.   I dabbled
>> in Enthought and the system python, but I've found Macports to more
>> reliably reproduce the pain-free python experience from linux.
>>
>>  For more on installing with macports:
>> http://astrofrog.github.io/macports-python/
>>
>>  Also, an aside, don't fret much about clobbering CASA.  It will happily
>> stay in its own little python world regardless of what python you're
>> installing.
>>
>>  ----Paul
>>
>>  On Apr 30, 2013, at 7:20 AM, Matt Davis wrote:
>>
>>  Hi Eric, I generally recommend the Anaconda distro:
>> http://continuum.io/downloads.html It's open source and supports setting
>> up different environments, and it's nicely self contained so it won't mess
>> with anything else you have installed. You can set it up on both Mac and
>> Linux without root.
>>
>>  Best,
>> Matt
>>
>>  On Apr 30, 2013, at 10:13 AM, "Eric L. N. Jensen" <
>> ejensen1 at swarthmore.edu>
>>  wrote:
>>
>> Hi,
>>
>> I've gradually been making the switch both to using Python more for my
>> data analysis, and also doing more of my work on a Mac rather than Linux.
>>  So I've decided it's time to get my Mac python distribution(s) in order
>> (there are several of them running around on my machine, from various
>> packages) and start fresh with a new python distro that I'll maintain as my
>> main work environment.
>>
>> The page at
>> http://python4astronomers.github.io/installation/python_install.htmlrecommends Enthought Python as a good place to start, but I find that this
>> has now changed to a different environment called Canopy.  Any opinions on
>> whether I should install Canopy, or choose a different distro?
>>
>> A few pieces of information that may be helpful in answering this:
>>
>> 1.  I'm running Mac OSX 10.7, 64-bit.
>> 2.  I'm comfortable installing/building software from the command line
>> (as root or not).
>> 3.  BUT all of my installation/sys-admin experience is with non-python
>> software, and much of it on Linux.  I don't have any experience with
>> managing a python environment, especially with multiple python
>> installations, and I don't want to mess up the system python install (or
>> the internal python installs for other software I have installed, like
>> CASA).
>> 4.  I *do* qualify for the Enthought academic license, so I can use that
>> rather than the free version.
>> 5.  If this goes well, I'd probably like to set up a similar environment
>> on my linux machine as well, though this is relatively low priority if
>> otherwise there's a good Mac-only solution.
>>
>> Thanks in advance for your help with this - let me know if there's other
>> info that would be useful.
>>
>> Eric Jensen
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>  _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>
> --
> Kelle Cruz, PhD ? http://kellecruz.com/
> 917.725.1334 ? Hunter: x16486 ? AMNH: x3404
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130509/456f4805/attachment.html>

From aleroy at nrao.edu  Fri May 10 14:57:09 2013
From: aleroy at nrao.edu (Adam Leroy)
Date: Fri, 10 May 2013 14:57:09 -0400
Subject: [AstroPy] Reprojecting each slice in a data cube based on
 another cube's WCS?
In-Reply-To: <A00F693E-04BD-4C4D-9BF7-CA0BFE48D89E@swarthmore.edu>
References: <A00F693E-04BD-4C4D-9BF7-CA0BFE48D89E@swarthmore.edu>
Message-ID: <518D4305.4050404@nrao.edu>

Hi Eric,

I should point out that CASA (the ALMA reduction software - 
casa.nrao.edu ) can also do this, including reprojection of the third 
axis (as frequency or velocity) and using another image as a template.

The functionality is wrapped up in a user friendly way in a task called 
'imregrid' and exists in a more configurable way in the CASA toolkit. 
I'd suggest grabbing the latest stable release 4.1.0 given that this 
task has seen some improvement in the last development cycle. If you go 
this route and have any issues, feel free to email me or contact the 
NRAO or ALMA helpdesk.

Regards,
Adam

On 5/8/13 3:58 PM, Eric L. N. Jensen wrote:
> Hi all,
>
> I'm working on a comparison of disk models to some ALMA synthesis imaging data, and in order to be able to compare models to data on a pixel-by-pixel basis, I'd like to be able to reproject each of the planes in a model data cube, based on the world coordinate system (WCS) information in the header of the observed data. I thought I might be able to do this with the python wrapper to Montage (using mProject), but it doesn't appear that mProject will handle 3D data (though I have posted a query to the Montage users' list as well to see if I'm missing something there).
>
> My files are FITS files with NAXIS = 3, where the first two axes are RA and Dec and the third axis is frequency or velocity, i.e. each slice of the third dimension is a 2-D image at a different frequency.
>
> The CRVAL/CDELT/CRPIX values of the third axis are already identical in both models and data, so no reprojection/resampling along the third axis is necessary - essentially I'm looking for an efficient way to spatially re-project each 2D image plane -  ideally without disassembling all the slices, reprojecting them individually, and reassembling them into a single file.
>
> I'm sure that python has various lower-level interpolation/resampling algorithms that I can use if necessary, but I'm hoping not to have to do the FITS header keyword parsing / recalculating / reprojecting work myself if this is already possible with existing high-level tools.  (The field of view is small, so it's really just a linear resampling problem, no complicated wide-field projection issues.)
>
> Thanks in advance for your help with this,
>
> Eric
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From ejensen1 at swarthmore.edu  Fri May 10 15:06:56 2013
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Fri, 10 May 2013 15:06:56 -0400
Subject: [AstroPy] Reprojecting each slice in a data cube based on
	another cube's WCS?
In-Reply-To: <518D4305.4050404@nrao.edu>
References: <A00F693E-04BD-4C4D-9BF7-CA0BFE48D89E@swarthmore.edu>
	<518D4305.4050404@nrao.edu>
Message-ID: <523184BD-7ED0-43C6-8966-5BA66A45C093@swarthmore.edu>

Ah, excellent!  Thanks so much - I had somehow missed that task in the documentation, but it's perfect for what I need.  I have it sort of working in CASA with imsubimage, but this will be much better. 

Thanks,

Eric

On May 10, 2013, at 2:57 PM, Adam Leroy wrote:

> I should point out that CASA (the ALMA reduction software - 
> casa.nrao.edu ) can also do this, including reprojection of the third 
> axis (as frequency or velocity) and using another image as a template.
> 
> The functionality is wrapped up in a user friendly way in a task called 
> 'imregrid' and exists in a more configurable way in the CASA toolkit. 
> I'd suggest grabbing the latest stable release 4.1.0 given that this 
> task has seen some improvement in the last development cycle. If you go 
> this route and have any issues, feel free to email me or contact the 
> NRAO or ALMA helpdesk.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130510/2023ea82/attachment.html>

From p.berrett at optusnet.com.au  Tue May 14 08:52:47 2013
From: p.berrett at optusnet.com.au (Peter Berrett)
Date: Tue, 14 May 2013 22:52:47 +1000
Subject: [AstroPy] Help with python image processing problem
Message-ID: <A427696DAE5543729C7AE624E6103853@PETESPC>

Hi all

I am new to this list and was hoping someone could help me with a programming problem.

I am writing a program in python to find sungrazer comets in soho telsescope c2 images. Normally they are pretty easy to find just by looking at processed images but finding these comets is pretty competitive to the point where comet-hunters now download raw images from the lasco archives in FITS format and process them themselves in order to gain minutes, and sometimes seconds advantage.

So if I am going to compete effectively I will need some software to do the same.

The images 1024 x 1024 are stored in .fts format on a server I can access. What I need is a python script to make a masterflat from the batch of available images and then another to subtract the masterflat from the image being processed. Would anyone have some python scripts that have already been prepared and can do this? I have looked at various image handling libraries to do this but they either lack documentation or are a bit difficult to work with for fits files.

I'd be grateful for any help anyone can provide.

Sample images can be seen at 

ftp://lasco6.nascom.asa.gov/asco/lastiage/level_05/130514/c2/
   

Basically I want to process these images and be able to turn them into processed gif or bmp files within a few seconds after a new file is added to the directory.

Thanking you

Peter Berrett




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130514/6142dcbb/attachment.html>

From jjk at uvic.ca  Tue May 14 09:48:56 2013
From: jjk at uvic.ca (JJ Kavelaars)
Date: Tue, 14 May 2013 09:48:56 -0400
Subject: [AstroPy] Help with python image processing problem
In-Reply-To: <A427696DAE5543729C7AE624E6103853@PETESPC>
References: <A427696DAE5543729C7AE624E6103853@PETESPC>
Message-ID: <8D109842-A0A4-4A30-A8CA-DB4AE5F7891A@uvic.ca>

This script:

<https://github.com/ijiraq/MOP/blob/master/src/jjk/preproc/preproc.py>

will do what you want with some modification.  This was written for CFHT MegaPrime images but would generally work on FITS.  The result is in 'FITS' at the end so you'll need to use a scaling/convert program to get them into jpg or load them into a browser as FITS (maybe using js9 if you are doing this via a web interface). 

That script is not documented very much.  --help provides some details and you need a bunch of other packages to get to going.

preproc.py --normal --combine --outfile=flat input1.fits input2.fits input3.fits ....

will build a 'flat' based those input images.

preproc.py --flat=flat.fits --outfile=image1_p.fits image1.fits  

will provide image1_p.fits flattened by flat.fits

There is some specific logic in the script to deal with file names when MEGAPIPE data is provided.  and the overscan/bias methods will only work on those data.  But you are free to use this as a starting point.

JJ

On 2013-05-14, at 8:52 AM, "Peter Berrett" <p.berrett at optusnet.com.au> wrote:

> Hi all
>  
> I am new to this list and was hoping someone could help me with a programming problem.
>  
> I am writing a program in python to find sungrazer comets in soho telsescope c2 images. Normally they are pretty easy to find just by looking at processed images but finding these comets is pretty competitive to the point where comet-hunters now download raw images from the lasco archives in FITS format and process them themselves in order to gain minutes, and sometimes seconds advantage.
>  
> So if I am going to compete effectively I will need some software to do the same.
>  
> The images 1024 x 1024 are stored in .fts format on a server I can access. What I need is a python script to make a masterflat from the batch of available images and then another to subtract the masterflat from the image being processed. Would anyone have some python scripts that have already been prepared and can do this? I have looked at various image handling libraries to do this but they either lack documentation or are a bit difficult to work with for fits files.
>  
> I'd be grateful for any help anyone can provide.
>  
> Sample images can be seen at
>  
> ftp://lasco6.nascom.asa.gov/asco/lastiage/level_05/130514/c2/
>    
>  
> Basically I want to process these images and be able to turn them into processed gif or bmp files within a few seconds after a new file is added to the directory.
>  
> Thanking you
>  
> Peter Berrett
>  
>  
>  
>  
>  
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130514/dcba124e/attachment.html>

From rolf.buehler at desy.de  Wed May 15 04:29:08 2013
From: rolf.buehler at desy.de (Rolf Buehler)
Date: Wed, 15 May 2013 10:29:08 +0200
Subject: [AstroPy] units in ascii read/write?
Message-ID: <51934754.3060103@desy.de>

Dear  Astropy developers,
thank you for this great tool, I have been looking for something like 
this for a long time.
I have a problem when reading in ascii files, the units dont get read 
nor saved in the  ascii.SExtractor format. Below I post more details.
Could you please tell me if this is currently a missinf feature or I am 
doing something wrong?
Thank you again and cheers,
Rolf

Example file I am reading:
#    1    flux    Fluss    [eV]
#    2    time    Zeit    [MJD]
1    34
3    56

data = 
ascii.read("sextractor.dat",Reader=ascii.SExtractor,guess=False,delimiter='\t',comment="#")

After I get:

In [49]: data["flux"]
Out[49]:
<Column name='flux' units=None format=None description=None>
array([1, 3])

So units are not there.

-- 
+49 337627-7249
www.rolfbuehler.net



From p.berrett at optusnet.com.au  Wed May 15 07:36:04 2013
From: p.berrett at optusnet.com.au (Peter Berrett)
Date: Wed, 15 May 2013 21:36:04 +1000
Subject: [AstroPy] Help with python image processing problem
In-Reply-To: <8D109842-A0A4-4A30-A8CA-DB4AE5F7891A@uvic.ca>
References: <A427696DAE5543729C7AE624E6103853@PETESPC>
	<8D109842-A0A4-4A30-A8CA-DB4AE5F7891A@uvic.ca>
Message-ID: <AA4D6A7CCFC141CDA0B0B809CF80718B@PETESPC>

Thanks

I shall give it a try and see if it works

cheers Peter



From: JJ Kavelaars 
Sent: Tuesday, May 14, 2013 11:48 PM
To: Peter Berrett 
Cc: <astropy at scipy.org> 
Subject: Re: [AstroPy] Help with python image processing problem


This script:


<https://github.com/ijiraq/MOP/blob/master/src/jjk/preproc/preproc.py>


will do what you want with some modification.  This was written for CFHT MegaPrime images but would generally work on FITS.  The result is in 'FITS' at the end so you'll need to use a scaling/convert program to get them into jpg or load them into a browser as FITS (maybe using js9 if you are doing this via a web interface). 


That script is not documented very much.  --help provides some details and you need a bunch of other packages to get to going.


preproc.py --normal --combine --outfile=flat input1.fits input2.fits input3.fits ....


will build a 'flat' based those input images.


preproc.py --flat=flat.fits --outfile=image1_p.fits image1.fits  


will provide image1_p.fits flattened by flat.fits


There is some specific logic in the script to deal with file names when MEGAPIPE data is provided.  and the overscan/bias methods will only work on those data.  But you are free to use this as a starting point.

JJ

On 2013-05-14, at 8:52 AM, "Peter Berrett" <p.berrett at optusnet.com.au> wrote:


  Hi all

  I am new to this list and was hoping someone could help me with a programming problem.

  I am writing a program in python to find sungrazer comets in soho telsescope c2 images. Normally they are pretty easy to find just by looking at processed images but finding these comets is pretty competitive to the point where comet-hunters now download raw images from the lasco archives in FITS format and process them themselves in order to gain minutes, and sometimes seconds advantage.

  So if I am going to compete effectively I will need some software to do the same.

  The images 1024 x 1024 are stored in .fts format on a server I can access. What I need is a python script to make a masterflat from the batch of available images and then another to subtract the masterflat from the image being processed. Would anyone have some python scripts that have already been prepared and can do this? I have looked at various image handling libraries to do this but they either lack documentation or are a bit difficult to work with for fits files.

  I'd be grateful for any help anyone can provide.

  Sample images can be seen at 

  ftp://lasco6.nascom.asa.gov/asco/lastiage/level_05/130514/c2/
     

  Basically I want to process these images and be able to turn them into processed gif or bmp files within a few seconds after a new file is added to the directory.

  Thanking you

  Peter Berrett





  _______________________________________________
  AstroPy mailing list
  AstroPy at scipy.org
  http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/9bcd3cd1/attachment.html>

From p.berrett at optusnet.com.au  Wed May 15 07:47:22 2013
From: p.berrett at optusnet.com.au (Peter Berrett)
Date: Wed, 15 May 2013 21:47:22 +1000
Subject: [AstroPy] Help with python image processing problem
In-Reply-To: <AA4D6A7CCFC141CDA0B0B809CF80718B@PETESPC>
References: <A427696DAE5543729C7AE624E6103853@PETESPC><8D109842-A0A4-4A30-A8CA-DB4AE5F7891A@uvic.ca>
	<AA4D6A7CCFC141CDA0B0B809CF80718B@PETESPC>
Message-ID: <8675AE9A20C3412AA9EEB0D0010FBCEE@PETESPC>

1st problem 

It requires me to import MOPfits

Where can I get MOPfits and can I get it for Python 2.7  in Windows?

cheers Peter



From: Peter Berrett 
Sent: Wednesday, May 15, 2013 9:36 PM
To: astropy at scipy.org 
Subject: Re: [AstroPy] Help with python image processing problem


Thanks

I shall give it a try and see if it works

cheers Peter



From: JJ Kavelaars 
Sent: Tuesday, May 14, 2013 11:48 PM
To: Peter Berrett 
Cc: <astropy at scipy.org> 
Subject: Re: [AstroPy] Help with python image processing problem


This script:


<https://github.com/ijiraq/MOP/blob/master/src/jjk/preproc/preproc.py>


will do what you want with some modification.  This was written for CFHT MegaPrime images but would generally work on FITS.  The result is in 'FITS' at the end so you'll need to use a scaling/convert program to get them into jpg or load them into a browser as FITS (maybe using js9 if you are doing this via a web interface). 


That script is not documented very much.  --help provides some details and you need a bunch of other packages to get to going.


preproc.py --normal --combine --outfile=flat input1.fits input2.fits input3.fits ....


will build a 'flat' based those input images.


preproc.py --flat=flat.fits --outfile=image1_p.fits image1.fits  


will provide image1_p.fits flattened by flat.fits


There is some specific logic in the script to deal with file names when MEGAPIPE data is provided.  and the overscan/bias methods will only work on those data.  But you are free to use this as a starting point.

JJ

On 2013-05-14, at 8:52 AM, "Peter Berrett" <p.berrett at optusnet.com.au> wrote:


  Hi all

  I am new to this list and was hoping someone could help me with a programming problem.

  I am writing a program in python to find sungrazer comets in soho telsescope c2 images. Normally they are pretty easy to find just by looking at processed images but finding these comets is pretty competitive to the point where comet-hunters now download raw images from the lasco archives in FITS format and process them themselves in order to gain minutes, and sometimes seconds advantage.

  So if I am going to compete effectively I will need some software to do the same.

  The images 1024 x 1024 are stored in .fts format on a server I can access. What I need is a python script to make a masterflat from the batch of available images and then another to subtract the masterflat from the image being processed. Would anyone have some python scripts that have already been prepared and can do this? I have looked at various image handling libraries to do this but they either lack documentation or are a bit difficult to work with for fits files.

  I'd be grateful for any help anyone can provide.

  Sample images can be seen at 

  ftp://lasco6.nascom.asa.gov/asco/lastiage/level_05/130514/c2/
     

  Basically I want to process these images and be able to turn them into processed gif or bmp files within a few seconds after a new file is added to the directory.

  Thanking you

  Peter Berrett





  _______________________________________________
  AstroPy mailing list
  AstroPy at scipy.org
  http://mail.scipy.org/mailman/listinfo/astropy



--------------------------------------------------------------------------------


_______________________________________________
AstroPy mailing list
AstroPy at scipy.org
http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/83ec759b/attachment.html>

From aldcroft at head.cfa.harvard.edu  Wed May 15 08:14:20 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Wed, 15 May 2013 08:14:20 -0400
Subject: [AstroPy] units in ascii read/write?
In-Reply-To: <51934754.3060103@desy.de>
References: <51934754.3060103@desy.de>
Message-ID: <CAGsQ-NtE5o6tiGJcjOoLnB+p8GdC6GUNMVTs16_74ZqtaYUYBA@mail.gmail.com>

Hi Rolf,

Unfortunately units parsing isn't currently supported in the SExtractor
format.

This should be relatively easy to add, but biggest question is about the
format of the header lines that provide the units.  In the example you
showed the column definition line ends with an optional set of units within
square brackets like [eV].  Are there any other variations in the header
format possible?  I looked at the SExtractor manual but there is no
specification of the output format(s).  My guess for a rule is that if a
header line ends with something in square brackets then that is a unit.  Do
you think that will work?  (I don't use SExtractor myself).

This is now issue 1093:
  https://github.com/astropy/astropy/issues/1093

Thanks,
Tom


On Wed, May 15, 2013 at 4:29 AM, Rolf Buehler <rolf.buehler at desy.de> wrote:

> Dear  Astropy developers,
> thank you for this great tool, I have been looking for something like
> this for a long time.
> I have a problem when reading in ascii files, the units dont get read
> nor saved in the  ascii.SExtractor format. Below I post more details.
> Could you please tell me if this is currently a missinf feature or I am
> doing something wrong?
> Thank you again and cheers,
> Rolf
>
> Example file I am reading:
> #    1    flux    Fluss    [eV]
> #    2    time    Zeit    [MJD]
> 1    34
> 3    56
>
> data =
>
> ascii.read("sextractor.dat",Reader=ascii.SExtractor,guess=False,delimiter='\t',comment="#")
>
> After I get:
>
> In [49]: data["flux"]
> Out[49]:
> <Column name='flux' units=None format=None description=None>
> array([1, 3])
>
> So units are not there.
>
> --
> +49 337627-7249
> www.rolfbuehler.net
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/113ba281/attachment.html>

From rolf.buehler at desy.de  Wed May 15 08:32:35 2013
From: rolf.buehler at desy.de (Rolf Buehler)
Date: Wed, 15 May 2013 14:32:35 +0200
Subject: [AstroPy] units in ascii read/write?
In-Reply-To: <CAGsQ-NtE5o6tiGJcjOoLnB+p8GdC6GUNMVTs16_74ZqtaYUYBA@mail.gmail.com>
References: <51934754.3060103@desy.de>
	<CAGsQ-NtE5o6tiGJcjOoLnB+p8GdC6GUNMVTs16_74ZqtaYUYBA@mail.gmail.com>
Message-ID: <51938063.60002@desy.de>

Hi Tim,
thank you very much for the quick response. I also did not find a 
document which defines the SExtractor format, I just started using it as 
an other python module (AstroAsciiData) uses it. I understood the 
convention as you said:

#    NR    name    comments also with spaces    [units in brackets]
value1    value2    etc..


(note the TABs above between columns)

I also looked through the SExtractor manual and found no defninition, so 
maybe the above will work?
It is also what the metnioned AstroAsciiData uses:

http://www.stecf.org/software/PYTHONtools/astroasciidata/manual/asciidata/node2.html#SECTION00025000000000000000

Thanks and cheers,
Rolf

+49 337627-7249
www.rolfbuehler.net

On 05/15/2013 02:14 PM, Tom Aldcroft wrote:
> uare brackets like [eV].  Are there any other variations in the header 
> format possible?  I looked at the SExtractor manual but there is no 
> specification of the output format(s).  My guess for a rule is that if 
> a header line ends with something in square brackets then that is a 
> unit.  Do you think that will work?  (I don't use SExtractor myself).



From ejensen1 at swarthmore.edu  Wed May 15 10:19:56 2013
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Wed, 15 May 2013 10:19:56 -0400
Subject: [AstroPy] units in ascii read/write?
In-Reply-To: <51938063.60002@desy.de>
References: <51934754.3060103@desy.de>
	<CAGsQ-NtE5o6tiGJcjOoLnB+p8GdC6GUNMVTs16_74ZqtaYUYBA@mail.gmail.com>
	<51938063.60002@desy.de>
Message-ID: <9B09AE00-FAA4-483D-944E-3AC34F3BC463@swarthmore.edu>

Hi all,

In Rolf's original example:

> Example file I am reading:
> #    1    flux    Fluss    [eV]
> #    2    time    Zeit    [MJD]
> 1    34
> 3    56
> 
> data = 
> ascii.read("sextractor.dat",Reader=ascii.SExtractor,guess=False,delimiter='\t',comment="#")
isn't it the case that the header lines would get discarded as comments, since they have the comment character prepended?  That's how I understood the documentation:

> comment : regular expression defining a comment line in table
> If the comment regular expression matches the beginning of a table line then that line will be discarded from header or data processing.

Now it may be that the units won't work in any case, but at least it might have a hope of getting the column labels, as long as it can parse the multi-line format. 

Thanks for clarifying,

Eric


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/493674af/attachment.html>

From jjk at uvic.ca  Wed May 15 11:33:29 2013
From: jjk at uvic.ca (JJ Kavelaars)
Date: Wed, 15 May 2013 11:33:29 -0400
Subject: [AstroPy] units in ascii read/write?
In-Reply-To: <9B09AE00-FAA4-483D-944E-3AC34F3BC463@swarthmore.edu>
References: <51934754.3060103@desy.de>
	<CAGsQ-NtE5o6tiGJcjOoLnB+p8GdC6GUNMVTs16_74ZqtaYUYBA@mail.gmail.com>
	<51938063.60002@desy.de>
	<9B09AE00-FAA4-483D-944E-3AC34F3BC463@swarthmore.edu>
Message-ID: <B770DB37-A247-4A5E-897E-131EDF281DC9@uvic.ca>

Sextractor can output votable, using hat would provide the rich Access you are hoping for.

JJ 

On 2013-05-15, at 10:19 AM, "Eric L. N. Jensen" <ejensen1 at swarthmore.edu> wrote:

> Hi all,
> 
> In Rolf's original example:
> 
>> Example file I am reading:
>> #    1    flux    Fluss    [eV]
>> #    2    time    Zeit    [MJD]
>> 1    34
>> 3    56
>> 
>> data = 
>> ascii.read("sextractor.dat",Reader=ascii.SExtractor,guess=False,delimiter='\t',comment="#")
> isn't it the case that the header lines would get discarded as comments, since they have the comment character prepended?  That's how I understood the documentation:
> 
>> comment : regular expression defining a comment line in table
>> If the comment regular expression matches the beginning of a table line then that line will be discarded from header or data processing.
> 
> Now it may be that the units won't work in any case, but at least it might have a hope of getting the column labels, as long as it can parse the multi-line format. 
> 
> Thanks for clarifying,
> 
> Eric
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/34d4d4d4/attachment.html>

From eric at naoj.org  Wed May 15 17:37:41 2013
From: eric at naoj.org (Eric Jeschke)
Date: Wed, 15 May 2013 11:37:41 -1000
Subject: [AstroPy] astropy reference
Message-ID: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>

I'm finishing up a paper and I need a reference for astropy.  Can someone
give me a journal (preferably) or barring that, a conference proceedings
reference to astropy?

May I also ask the astropy admins to update the affiliated package link for
Ginga and put in the PyPI link?  (https://pypi.python.org/pypi/ginga)

Thanks,
~Eric

-- 
Eric Jeschke          |    eric at naoj.org    | ????,???
Software Engineer     |     808-934-5908    | ???????????
Subaru Telescope      |                     | ??????
National Astronomical Observatory of Japan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/772a5a7a/attachment.html>

From tim.jenness at gmail.com  Wed May 15 20:14:18 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 15 May 2013 17:14:18 -0700
Subject: [AstroPy] astropy reference
In-Reply-To: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
References: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
Message-ID: <CA+G92ReBOpX=u3sT9mUEcscxjpxa9z+NoaFR-Nz22MJeXZ-eJw@mail.gmail.com>

Erik presented a talk at the ADASS conference last October. That
publication should be out soon (if it was written up). I don't recall Erik
sending it round to the list though.

http://www.ncsa.illinois.edu/Conferences/ADASS2012/program/orals.html#Tollerud

something like:

@inproceedings{ astropy_adassxii,
   author = {E. Tollerud and P. Greenfield and T. Robitaille},
   booktitle = "ADASS XXII",
   year = 2013,
   editor = {D. Friedel and M. Freemon and R. Plante},
   series = "ASP Conf Ser.",
   volume = "TBD",
   pages = "in press",
   publisher = "ASP",
   address = "San Francisco"
 }





On Wed, May 15, 2013 at 2:37 PM, Eric Jeschke <eric at naoj.org> wrote:

>
> I'm finishing up a paper and I need a reference for astropy.  Can someone
> give me a journal (preferably) or barring that, a conference proceedings
> reference to astropy?
>
> May I also ask the astropy admins to update the affiliated package link
> for Ginga and put in the PyPI link?  (https://pypi.python.org/pypi/ginga)
>
> Thanks,
> ~Eric
>
> --
> Eric Jeschke          |    eric at naoj.org    | ????,???
> Software Engineer     |     808-934-5908    | ???????????
> Subaru Telescope      |                     | ??????
> National Astronomical Observatory of Japan
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/91ffce9e/attachment.html>

From eric at naoj.org  Wed May 15 21:16:37 2013
From: eric at naoj.org (Eric Jeschke)
Date: Wed, 15 May 2013 15:16:37 -1000
Subject: [AstroPy] astropy reference
In-Reply-To: <CA+G92ReBOpX=u3sT9mUEcscxjpxa9z+NoaFR-Nz22MJeXZ-eJw@mail.gmail.com>
References: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
	<CA+G92ReBOpX=u3sT9mUEcscxjpxa9z+NoaFR-Nz22MJeXZ-eJw@mail.gmail.com>
Message-ID: <CA+PoO+W2AB3iOJjDEwEq1eoDkvPSqyeLOh-7hra-_dvosBEMSQ@mail.gmail.com>

Thanks, Tim.  I have a paper in there myself, the problem is that volume is
not yet published.  Looking for a published reference, if possible.  If I
can't find one I'll simply reference the web site.

~Eric


On Wed, May 15, 2013 at 2:14 PM, Tim Jenness <tim.jenness at gmail.com> wrote:

> Erik presented a talk at the ADASS conference last October. That
> publication should be out soon (if it was written up). I don't recall Erik
> sending it round to the list though.
>
>
> http://www.ncsa.illinois.edu/Conferences/ADASS2012/program/orals.html#Tollerud
>
> something like:
>
> @inproceedings{ astropy_adassxii,
>    author = {E. Tollerud and P. Greenfield and T. Robitaille},
>    booktitle = "ADASS XXII",
>    year = 2013,
>    editor = {D. Friedel and M. Freemon and R. Plante},
>    series = "ASP Conf Ser.",
>    volume = "TBD",
>    pages = "in press",
>    publisher = "ASP",
>    address = "San Francisco"
>  }
>
>
>
>
>
> On Wed, May 15, 2013 at 2:37 PM, Eric Jeschke <eric at naoj.org> wrote:
>
>>
>> I'm finishing up a paper and I need a reference for astropy.  Can someone
>> give me a journal (preferably) or barring that, a conference proceedings
>> reference to astropy?
>>
>> May I also ask the astropy admins to update the affiliated package link
>> for Ginga and put in the PyPI link?  (https://pypi.python.org/pypi/ginga)
>>
>> Thanks,
>> ~Eric
>>
>> --
>> Eric Jeschke          |    eric at naoj.org    | ????,???
>> Software Engineer     |     808-934-5908    | ???????????
>> Subaru Telescope      |                     | ??????
>> National Astronomical Observatory of Japan
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>


-- 
Eric Jeschke          |    eric at naoj.org    | ????,???
Software Engineer     |     808-934-5908    | ???????????
Subaru Telescope      |                     | ??????
National Astronomical Observatory of Japan

http://naoj.org/staff/eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/4dd92abe/attachment.html>

From tim.jenness at gmail.com  Thu May 16 00:02:19 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 15 May 2013 21:02:19 -0700
Subject: [AstroPy] astropy reference
In-Reply-To: <CA+PoO+W2AB3iOJjDEwEq1eoDkvPSqyeLOh-7hra-_dvosBEMSQ@mail.gmail.com>
References: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
	<CA+G92ReBOpX=u3sT9mUEcscxjpxa9z+NoaFR-Nz22MJeXZ-eJw@mail.gmail.com>
	<CA+PoO+W2AB3iOJjDEwEq1eoDkvPSqyeLOh-7hra-_dvosBEMSQ@mail.gmail.com>
Message-ID: <CA+G92RfW8efVJuaLHW11435S_N2cYNaNLPcwVLYWYndyX2duhQ@mail.gmail.com>

In press is a reasonable thing to cite, especially if your paper will take
a few months to appear. I also can't see what's wrong with citing both the
in press paper and the web site.

Erik could also upload it to arXiv as a preprint.


On Wed, May 15, 2013 at 6:16 PM, Eric Jeschke <eric at naoj.org> wrote:

> Thanks, Tim.  I have a paper in there myself, the problem is that volume
> is not yet published.  Looking for a published reference, if possible.  If
> I can't find one I'll simply reference the web site.
>
> ~Eric
>
>
> On Wed, May 15, 2013 at 2:14 PM, Tim Jenness <tim.jenness at gmail.com>wrote:
>
>> Erik presented a talk at the ADASS conference last October. That
>> publication should be out soon (if it was written up). I don't recall Erik
>> sending it round to the list though.
>>
>>
>> http://www.ncsa.illinois.edu/Conferences/ADASS2012/program/orals.html#Tollerud
>>
>> something like:
>>
>> @inproceedings{ astropy_adassxii,
>>    author = {E. Tollerud and P. Greenfield and T. Robitaille},
>>    booktitle = "ADASS XXII",
>>    year = 2013,
>>    editor = {D. Friedel and M. Freemon and R. Plante},
>>    series = "ASP Conf Ser.",
>>    volume = "TBD",
>>    pages = "in press",
>>    publisher = "ASP",
>>    address = "San Francisco"
>>  }
>>
>>
>>
>>
>>
>> On Wed, May 15, 2013 at 2:37 PM, Eric Jeschke <eric at naoj.org> wrote:
>>
>>>
>>> I'm finishing up a paper and I need a reference for astropy.  Can
>>> someone give me a journal (preferably) or barring that, a conference
>>> proceedings reference to astropy?
>>>
>>> May I also ask the astropy admins to update the affiliated package link
>>> for Ginga and put in the PyPI link?  (https://pypi.python.org/pypi/ginga
>>> )
>>>
>>> Thanks,
>>> ~Eric
>>>
>>> --
>>> Eric Jeschke          |    eric at naoj.org    | ????,???
>>>
>>> Software Engineer     |     808-934-5908    | ???????????
>>> Subaru Telescope      |                     | ??????
>>>
>>> National Astronomical Observatory of Japan
>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>>
>>
>
>
> --
> Eric Jeschke          |    eric at naoj.org    | ????,???
> Software Engineer     |     808-934-5908    | ???????????
> Subaru Telescope      |                     | ??????
> National Astronomical Observatory of Japan
>
> http://naoj.org/staff/eric
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130515/632f3efc/attachment.html>

From erik.tollerud at gmail.com  Sat May 18 20:20:42 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Sat, 18 May 2013 20:20:42 -0400
Subject: [AstroPy] astropy reference
In-Reply-To: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
References: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
Message-ID: <CAARXUwWSrs1v2U31AS+BtZNvj+_BiMj28myc3=po5APL9VK+7A@mail.gmail.com>

Unfortunately, there is not a published citation available yet.  A few
options that come to mind:

* Cite the forthcoming A&A paper (see
https://github.com/astropy/astropy-v0.2-paper for a current draft) - it's
not submitted yet, but depending on how long your paper takes to be in
press, we may at least have an astro-ph preprint out by the time you're
doing proofs.
* Cite our Astronomy Source Code Library entry (
http://asterisk.apod.com/viewtopic.php?f=35&t=31097&p=196496#p196496).  The
ASCL is now indexed by ADS, so it should be there at
http://adsabs.harvard.edu/abs/2013ascl.soft04002C , but it was only a few
weeks back that it got put up, so I don't think ADS has it yet.  You can
look at http://asterisk.apod.com/wp/?page_id=351 for info on how to cite
ASCL entries, or if that doesn't help, I can send you an example of how
I've done this before in a way that ApJ deemed sufficient.
* Cite my ADASS conference proceeding as Tim suggested as "in press" or
similar.  I'd prefer not to put it on arXiv unless absolutely necessary,
because the hope was to get people to cite the A&A paper and not confuse
them with a few different things to cite.  Apparently you're just too on
top of things and are publishing before we expected anyone to, Eric :)

Once the A&A paper is up, we'll probably encourage people to always  cite
the latest A&A paper and/or the ASCL entry (although we haven't finalized a
"policy" yet).



On Wed, May 15, 2013 at 5:37 PM, Eric Jeschke <eric at naoj.org> wrote:

>
> I'm finishing up a paper and I need a reference for astropy.  Can someone
> give me a journal (preferably) or barring that, a conference proceedings
> reference to astropy?
>
> May I also ask the astropy admins to update the affiliated package link
> for Ginga and put in the PyPI link?  (https://pypi.python.org/pypi/ginga)
>
> Thanks,
> ~Eric
>
> --
> Eric Jeschke          |    eric at naoj.org    | ????,???
> Software Engineer     |     808-934-5908    | ???????????
> Subaru Telescope      |                     | ??????
> National Astronomical Observatory of Japan
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130518/ae0ca101/attachment.html>

From eric at naoj.org  Sat May 18 23:17:12 2013
From: eric at naoj.org (Eric Jeschke)
Date: Sat, 18 May 2013 17:17:12 -1000
Subject: [AstroPy] astropy reference
In-Reply-To: <CAARXUwWSrs1v2U31AS+BtZNvj+_BiMj28myc3=po5APL9VK+7A@mail.gmail.com>
References: <CA+PoO+Whpcj6KxrhRacJUi-yLU6Px6Xe93poJfNk24W80SSRxg@mail.gmail.com>
	<CAARXUwWSrs1v2U31AS+BtZNvj+_BiMj28myc3=po5APL9VK+7A@mail.gmail.com>
Message-ID: <CA+PoO+UQbOxHTAxcnQGRfry9KtZqLTTiFuHvn=HQbjSj7MS=dQ@mail.gmail.com>

Thanks for the reply, Erik.  I did as Tim suggested and cited the ADASS
paper "in press".

Regards,
~Eric


On Sat, May 18, 2013 at 2:20 PM, Erik Tollerud <erik.tollerud at gmail.com>wrote:

> Unfortunately, there is not a published citation available yet.  A few
> options that come to mind:
>
> * Cite the forthcoming A&A paper (see
> https://github.com/astropy/astropy-v0.2-paper for a current draft) - it's
> not submitted yet, but depending on how long your paper takes to be in
> press, we may at least have an astro-ph preprint out by the time you're
> doing proofs.
> * Cite our Astronomy Source Code Library entry (
> http://asterisk.apod.com/viewtopic.php?f=35&t=31097&p=196496#p196496).
>  The ASCL is now indexed by ADS, so it should be there at
> http://adsabs.harvard.edu/abs/2013ascl.soft04002C , but it was only a few
> weeks back that it got put up, so I don't think ADS has it yet.  You can
> look at http://asterisk.apod.com/wp/?page_id=351 for info on how to cite
> ASCL entries, or if that doesn't help, I can send you an example of how
> I've done this before in a way that ApJ deemed sufficient.
> * Cite my ADASS conference proceeding as Tim suggested as "in press" or
> similar.  I'd prefer not to put it on arXiv unless absolutely necessary,
> because the hope was to get people to cite the A&A paper and not confuse
> them with a few different things to cite.  Apparently you're just too on
> top of things and are publishing before we expected anyone to, Eric :)
>
> Once the A&A paper is up, we'll probably encourage people to always  cite
> the latest A&A paper and/or the ASCL entry (although we haven't finalized a
> "policy" yet).
>
>
>
> On Wed, May 15, 2013 at 5:37 PM, Eric Jeschke <eric at naoj.org> wrote:
>
>>
>> I'm finishing up a paper and I need a reference for astropy.  Can someone
>> give me a journal (preferably) or barring that, a conference proceedings
>> reference to astropy?
>>
>> May I also ask the astropy admins to update the affiliated package link
>> for Ginga and put in the PyPI link?  (https://pypi.python.org/pypi/ginga)
>>
>> Thanks,
>> ~Eric
>>
>> --
>> Eric Jeschke          |    eric at naoj.org    | ????,???
>> Software Engineer     |     808-934-5908    | ???????????
>> Subaru Telescope      |                     | ??????
>> National Astronomical Observatory of Japan
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
>
> --
> Erik
>



-- 
Eric Jeschke          |    eric at naoj.org    | ????,???
Software Engineer     |     808-934-5908    | ???????????
Subaru Telescope      |                     | ??????
National Astronomical Observatory of Japan

http://naoj.org/staff/eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130518/485ccf7e/attachment.html>

From hack at stsci.edu  Tue May 21 11:11:07 2013
From: hack at stsci.edu (Warren J. Hack)
Date: Tue, 21 May 2013 11:11:07 -0400
Subject: [AstroPy] TABLES/STSDAS v3.16 and STSCI_PYTHON v2.14 NOW AVAILABLE
Message-ID: <519B8E8B.4020106@stsci.edu>

     ********************************************************

     TABLES/STSDAS v3.16 and STSCI_PYTHON v2.14 NOW AVAILABLE

     ********************************************************


The Science Software Branch of the Space Telescope Science Institute
wishes to announce the availability of these packages:

      v3.16 of the Space Telescope Science Data Analysis Software (STSDAS)
      v3.16 of the TABLES external package
      v1.2 of the HSTCAL package
      v2.14 of STScI_Python

Both the STSDAS and Tables packages are layered upon IRAF as external
packages; it is therefore necessary to obtain and install IRAF
(from http://iraf.noao.edu) before installing TABLES and STSDAS.
STSDAS is linked against libraries in TABLES, so TABLES must be
installed before STSDAS.

The HSTCAL package contains HST pipelines that formerly required
IRAF, but now have no IRAF dependencies, and can be used without
requiring IRAF to be installed.

The STScI_Python package can be installed independent of IRAF, with
the PyRAF package providing a Python interface to IRAF should it be
installed.

------
STSDAS
------
This release of STSDAS contains changes to COS, and WFC3.
This release includes the same versions of the calibration software
used in the pipeline to support most of the active HST instruments
using the algorithms developed from the data taken during Servicing
Mission 4, especially for the Wide Field Camera 3(WFC3) and the
Cosmic Origins Spectrograph(COS). For WFC3, calwf3 has been frozen
with continued development taking place under HSTCAL. The next
release will not contain any updates to calstis either as the next version
of calstis will be released under HSTCAL as well.

STSDAS also includes some Python-based tasks; running these requires the
STScI Python Libraries to be installed (all the non-Python tasks can
be used in the traditional way and do not require Python or the STScI
Python libraries). These tasks can only be run from PyRAF using standard
IRAF CL task syntax, or within Python scripts using Python syntax.
One such set of tasks, the aXe package, was updated to allow use of
AstroDrizzle for catalog generation.

HSTCAL and Future STSDAS Releases
=================================
The HSTCAL package now contains versions of both CALACS and CALWF3
which no longer depend on IRAF at all. These versions have become
the sole versions being supported by STScI for calibrating ACS and
WFC3 data, with the most recent updates only being implemented
in the HSTCAL versions of those tasks. The out-dated code for CALWF3
has been removed entirely from STSDAS. Any user loading the 'wfc3' package
under STSDAS will be directed to the HSTCAL version which now has
a Python-based TEAL interface as well as the standard command-line
executable interface.

The STSDAS version of CALSTIS will also be removed in
future releases as it gets replaced by the HSTCAL version of the code.

stecf software
==============
This release contains the stecf IRAF package for
supporting HST data that had been developed by members of the Space
Telescope European Coordinating Facility (ST-ECF) which closed on 31
December 2010.  Support for these packages may be obtained by contacting
the STScI Help Desk at 'help at stsci.edu'. These questions will then be
forwarded to the package authors at ESO as required.

STSDAS Platform Support
=======================
Binaries for this release were built on Red Hat Enterprise Linux 5
and Mac OS X 10.5.  Binaries were built with IRAF 2.14.  Binaries
for newer versions of IRAF or operating systems may be built as
needed, and users can check the STSDAS web pages for more
details.

IRAF is available from http://iraf.net.

No Solaris Support for STSDAS
-----------------------------
This version was not built or tested on Solaris. The source code, however,
can always be downloaded and compiled locally as needed.

64-bit IRAF Support
===================
IRAF 2.15 includes support for 64-bit systems. The changes necessary to
support 64-bits generally require applications to be modified. We will
only release 32-bit binaries fo the Tables and STSDAS packages for use
with IRAF 2.15. Support for 32-bit binaries will continue as long as
there are sufficient plaforms that such binaries will run on. We may
only convert some packages in Tables and STSDAS to 64-bit version when
the 32-bit versions are no longer viable and if created will be released
as a separate package with a different name. When the 32-bit versions
of TABLES and STSDAS are no longer viable, support for any tasks within
those packages not ported to 64-bits will end.  The full description of
this policy can be found online at:

http://www.stsci.edu/resources/software_hardware/stsdas/iraf64

------
Tables
------
This distribution of TABLES includes the TTOOLS package, as well
as FITSIO, and TBPLOT, along with the gflib, stxtools, and tbtables
libraries.  All these packages and libraries have been compiled to run
under 32-bit IRAF only, in contrast to the 64-bit version of TTOOLS
(installed as NTTOOLS) and the tbtables library supported by IRAF and
included in IRAF 2.15. This package is required for use with STSDAS.


--------------
HSTCAL Package
--------------
The HSTCAL package provides an environment for compiling IRAF tasks
written in C without using IRAF at all.  The HSTIO image and
tables C API has been replicated using CFITSIO. This API was
used to compile the ACS calibration code CALACS and WFC3 calibration
code CALWF3 without IRAF. This version of CALWF3, Version 3.0, was
installed in Nov 2012 as the calibration software that gets used in
the archive and for pipeline calibrations, replacing the now outdated
STSDAS/IRAF based version (both of which have been removed from STSDAS).


------------
STScI_Python
------------

STScI_Python is a collection of Python modules, packages and C 
extensions that
has been developed to provide a general astronomical data analysis
infrastructure. They can be used for Python tasks that are accessible from
within STSDAS when running under PyRAF or standalone from within Python.

This distribution continues to develop packages with tasks specific to
each HST instrument, with updates being made to calibration code for
COS (calcos v2.19.7), while adding tasks for working with ACS and COS 
data. This
release includes drizzlepac (the replacement for MultiDrizzle and the 
STSDAS
dither package) and fitsblender.  Updates were also made to pyraf, stwcs,
acstools, costools, wfc3tools, stistools and stsci.tools. PyRAF v2.0 now
supports both Python 2 and 3, amongst its many updates. The TEAL interface
for CALACS tasks and for the the CTE were also added to the acstools 
package.
Updates to calcos include reordering of some of the calibration steps,
along with bug fixes in acs_destripe and other improvements.

This release also contains pysynphot v0.9.5 which contains several bug
fixes and improvements for some calculations.

This release has been tested using Python Versions 2.6.5 and 2.7.3. This
release also requires at least numpy 1.5.  All packages within this
release have been revised to support easy_install of the code, while
still allowing the code to be installed using the disutils command
'python setup.py'.

MAJOR CHANGE TO INSTALLATION PROCEDURES
=======================================
The STScI_Python software has been re-packaged in this release to
install each package separately using standard Python installation
tools such as pip and easy_install.  This also allows each package
to be updated separately rather than having to update all at once.
The entire suite of software can still be installed in one command
that retrieves the software from the Python Package Index (PyPI)
directly.  A full description of this change and how to get and
install this software can be found on our web page at:

http://www.stsci.edu/institute/software_hardware/pyraf/stsci_python/installation


End of Python 2.5 support
=========================
Many of the packages in this distribution, including the new drizzlepac
package, have been implemented using features not available under
Python 2.5 in preparation for the transition to Python 3.x.  Future
releases will only support Python 2.6 or newer as part of this transition,
and all testing of our code under Python 2.5 has been terminated.

Python 3.x support
==================
The majority of stsci_python does not yet support Python 3.  While the scope
of the work involved in transitioning to Python 3.x is being considered, be
aware that we expect to support Python 2.x for quite some time.  At this
time however, both the PyFITS and the PyRAF packages support Python 3.2 (as
well as Python 2).

Platform Support
================
This testing took place under Linux (Red Hat Enterprise 5 and 6) and
Mac OS X (both 10.5 and 10.6), but testing no longer takes place on 
Solaris.

STSCI_Python on WINDOWS
=======================
This release includes a port of stsci_python that runs natively under
Windows. PyRAF also now comes as part of the installation under Windows,
complete with its own desktop shortcut, albeit without IRAF.

The primary requirement for use of this installer is that the Windows
executables were built against and, therefore, can run only under
Python 2.7.

STScI_Python and astropy
========================
Some packages currently distributed as part of stsci_python provide
more general functionality beyond that needed by HST data; packages
such as pyfits and vo.  Those packages have started to migrate to the
more general astropy distribution. Our code which uses those libraries
(specifically, pyfits and pywcs) will be updated to use the astropy core
libraries in the next release (Fall 2013).  Stand-alone releases of
those libraries will still remain available for that release, but will
eventually stop being released outside of astropy. The astropy
distribution, along with more details about the code included, can
be found at:

     http://www.astropy.org

Users and developers are encouraged to start reviewing how to transition
your own code to use astropy as soon as possible so that these dependencies
will not pose any problems in the future.  The API for PyFITS has not (yet)
changed in astropy relative to the stand-alone version, so this transition
should only require a simple change to what package gets imported for use
in the code.

=============================
WHERE TO OBTAIN THIS SOFTWARE
=============================
STSDAS/TABLES can be downloaded from the STSDAS web site.
The installation instructions for all these packages have changed.
You can now download a single tar file that contains the source code and
binaries for STSDAS, TABLES, and STECF.  There is also a smaller file
if you just need TABLES.  You can see the new installation instructions at

     http://www.stsci.edu/resources/software_hardware/stsdas/download

Installation instructions are available on the web site. Precompiled
binaries also exist for some of the ports supported by NOAO, including
RedHat Linux and Mac OS X.

STSCI_PYTHON be downloaded and installed using the instructions found at:

http://www.stsci.edu/institute/software_hardware/pyraf/stsci_python/installation

Installation instructions are available from this STScI_Python web site, 
with
support for installations on RedHat Linux, Mac OS X, and Windows.

Please contact us through e-mail (help at stsci.edu), by telephone at
(410) 338-1082.


From erik.tollerud at gmail.com  Wed May 22 15:35:32 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 22 May 2013 15:35:32 -0400
Subject: [AstroPy] ANN: Astropy 0.2.2 Released
Message-ID: <CAARXUwU_BYcyQZBwAw5ZBn=oW7EUH70w2hef3CmSF8HEGGyQLQ@mail.gmail.com>

Dear colleagues,

We are happy to announce the release of v0.2.2 of the Astropy package, a
core Python package for Astronomy.

v0.2.2 is a bug fix release, with 30+ bugfixes and performance
enhancements.  The full list of  changes can be found at
http://docs.astropy.org/en/v0.2.2/changelog.html#id1


Instructions for installing Astropy are provided at the
http://www.astropy.org website, and extensive documentation can be found at:

   http://docs.astropy.org

Downloads of this release (source code and installers) are available at
https://pypi.python.org/pypi/astropy/0.2.2


Thanks to all those who put time and effort into this release!

Erik Tollerud, Thomas Robitaille, and Perry Greenfield
on behalf of The Astropy Collaboration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130522/35c7ddc8/attachment.html>

From iancze at gmail.com  Wed May 22 17:02:02 2013
From: iancze at gmail.com (Ian Czekala)
Date: Wed, 22 May 2013 17:02:02 -0400
Subject: [AstroPy] SIMBAD Queries in Python
Message-ID: <CA+cQX8ZN2a8=y4v57MAmifGp-qgmnz2uTGdRnDwo+e04Ut8Cwg@mail.gmail.com>

Dear astropy and astroquery developers*,

I have a functionality question for astroquery.simbad. I would like to
query objects by ID and return more information than just the default
RA/DEC positions, such as magnitudes in a variety of filters and spectral
type, similar to the following query using
http://simbad.u-strasbg.fr/simbad/sim-fscript:

format object form1 "%IDLIST(1), %COO(A), %COO(D), %SP(S),
%FLUXLIST(U,B,V,R,I,J,H,K;N=F [E])"
query id HD 163296

To do this in astroquery, I use:

r = astroquery.simbad.QueryId("HD 163296").execute()
print(r.table)

but this only returns the RA/DEC (and precision). I was digging around the
github repo, but couldn't find a way to set the query return format,
similar to the first line in my simbad-script example. Does anyone know if
it might be possible to return fluxes etc from SIMBAD all within python?

Thank you very much!

Ian Czekala
iancze at gmail.com

*Apologies to those at CfA that have received this twice, Tom advised me to
post here instead!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130522/6914d338/attachment.html>

From emraydin at gmail.com  Thu May 23 05:26:50 2013
From: emraydin at gmail.com (=?ISO-8859-9?Q?Emre_Ayd=FDn?=)
Date: Thu, 23 May 2013 12:26:50 +0300
Subject: [AstroPy] SIMBAD Queries in Python
In-Reply-To: <CA+cQX8ZN2a8=y4v57MAmifGp-qgmnz2uTGdRnDwo+e04Ut8Cwg@mail.gmail.com>
References: <CA+cQX8ZN2a8=y4v57MAmifGp-qgmnz2uTGdRnDwo+e04Ut8Cwg@mail.gmail.com>
Message-ID: <CANu3TRov7yjuB0Wmt+W+hoD9Tqpknec8KiB30+MmV_vV_ndH=Q@mail.gmail.com>

Hi Ian,

Years ago I had a similar problem for an observatory database, so I wrote a
Python Library that parses HTML with regular expressions and returns
whatever you want. It is also a standalone executable, or you can import it
for any other Python script and just get the results you want.

Here is the link, hope it helps.

https://github.com/eaydin/PySIMBAD


On Thu, May 23, 2013 at 12:02 AM, Ian Czekala <iancze at gmail.com> wrote:

> Dear astropy and astroquery developers*,
>
> I have a functionality question for astroquery.simbad. I would like to
> query objects by ID and return more information than just the default
> RA/DEC positions, such as magnitudes in a variety of filters and spectral
> type, similar to the following query using
> http://simbad.u-strasbg.fr/simbad/sim-fscript:
>
> format object form1 "%IDLIST(1), %COO(A), %COO(D), %SP(S),
> %FLUXLIST(U,B,V,R,I,J,H,K;N=F [E])"
> query id HD 163296
>
> To do this in astroquery, I use:
>
> r = astroquery.simbad.QueryId("HD 163296").execute()
> print(r.table)
>
> but this only returns the RA/DEC (and precision). I was digging around the
> github repo, but couldn't find a way to set the query return format,
> similar to the first line in my simbad-script example. Does anyone know if
> it might be possible to return fluxes etc from SIMBAD all within python?
>
> Thank you very much!
>
> Ian Czekala
> iancze at gmail.com
>
> *Apologies to those at CfA that have received this twice, Tom advised me
> to post here instead!
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>


-- 
M. EMRE AYDIN
emraydin at gmail.com
about.me/emre.aydin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130523/7b9d5164/attachment.html>

From thomas.robitaille at gmail.com  Tue May 28 10:35:51 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 28 May 2013 16:35:51 +0200
Subject: [AstroPy] Astropy Google Summer of Code students announced!
Message-ID: <CAGMHX_1RAyv3aKa0EPdV0V1UWd+NMD_N02Nr2XN51KmQTuAUSQ@mail.gmail.com>

Hi everyone,

I am very happy to announce that two students will be joining the
Astropy project this summer as part of the Google Summer of Code
program!

The selected students are:

- Madhura Parikh, who will be working on the Astroquery affiliated
package. Astroquery aims to provide a Python interface to many web
services such as IRSA, SIMBAD, VizieR, and many others. Madhura will
be refactoring it to unify the API, with the aim of a first stable
release at the end of the summer.

- Axel Donath, who will be working on significantly extending the
capabilities of the Photutils affiliated package. Photutils aims to
provide Python tools to perform aperture and PSF photometry, and the
long-term goal is to integrate it into the core Astropy package. Axel
will focus on developing the source detection and PSF-fitting
functionality which are currently missing.

Competition for GSoC was tough this year, and there were a number of
excellent applications to work with Astropy, so I want to thank all
the students who applied to work with us!

The official GSoC mentors for Astropy are Tom Aldcroft, Adam Ginsburg,
Wolfgang Kerzendorf, Adrian Price-Whelan, Erik Tollerud, and myself.
Throughout the summer, Madhura and Axel will be communicating with the
Astropy development team through the astropy-dev list, so if you are
interested in either of the projects mentioned above, please feel free
to get involved in the discussions!

Cheers,
Tom


From rhl at astro.princeton.edu  Tue May 28 14:13:32 2013
From: rhl at astro.princeton.edu (Robert Lupton the Good)
Date: Tue, 28 May 2013 14:13:32 -0400
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
In-Reply-To: <mailman.1.1369760402.7575.astropy@scipy.org>
References: <mailman.1.1369760402.7575.astropy@scipy.org>
Message-ID: <54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>

> Axel will focus on developing the source detection and PSF-fitting functionality which are currently missing.

As you may or may not know, LSST is putting a lot of effort into industrial-scale processing of CCD data and we have all this sort of thing working quite nicely.  LSST doesn't have the same goal as astropy (as LSST uses C++ classes), but we should stay in contact.

							R

P.S. if Obama's budget passes and LSST gets an MREFC start, I'll be hiring people...




From jturner at gemini.edu  Tue May 28 16:21:35 2013
From: jturner at gemini.edu (James Turner)
Date: Tue, 28 May 2013 16:21:35 -0400
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
In-Reply-To: <54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
References: <mailman.1.1369760402.7575.astropy@scipy.org>
	<54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
Message-ID: <51A511CF.80307@gemini.edu>

>> Axel will focus on developing the source detection and PSF-fitting functionality which are currently missing.
>
> As you may or may not know, LSST is putting a lot of effort into industrial-scale processing of CCD data and we have all this sort of thing working quite nicely.  LSST doesn't have the same goal as astropy (as LSST uses C++ classes), but we should stay in contact.

Do you have a link to that source detection stuff?

Thanks,

James.



From npkuin at gmail.com  Tue May 28 16:52:29 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Tue, 28 May 2013 21:52:29 +0100
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
In-Reply-To: <54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
References: <mailman.1.1369760402.7575.astropy@scipy.org>
	<54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
Message-ID: <CANoQ6N12RSkQX__=HAWdJ2f6RZnojEnk5FE8SiUTNn0AvvTGpw@mail.gmail.com>

Hi Robert,

BTW, Python can just call all those fancy C++ routines and provide
wrappers.

At the same time, I wonder if that LSST software can be used freely or will
have export restrictions ?

Cheers,

Paul


On Tue, May 28, 2013 at 7:13 PM, Robert Lupton the Good <
rhl at astro.princeton.edu> wrote:

> > Axel will focus on developing the source detection and PSF-fitting
> functionality which are currently missing.
>
> As you may or may not know, LSST is putting a lot of effort into
> industrial-scale processing of CCD data and we have all this sort of thing
> working quite nicely.  LSST doesn't have the same goal as astropy (as LSST
> uses C++ classes), but we should stay in contact.
>
>                                                         R
>
> P.S. if Obama's budget passes and LSST gets an MREFC start, I'll be hiring
> people...
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204927 (work) -276110 (home)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130528/fd317a03/attachment.html>

From rhl at astro.princeton.edu  Tue May 28 16:56:17 2013
From: rhl at astro.princeton.edu (Robert Lupton the Good)
Date: Tue, 28 May 2013 16:56:17 -0400
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
In-Reply-To: <CANoQ6N12RSkQX__=HAWdJ2f6RZnojEnk5FE8SiUTNn0AvvTGpw@mail.gmail.com>
References: <mailman.1.1369760402.7575.astropy@scipy.org>
	<54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
	<CANoQ6N12RSkQX__=HAWdJ2f6RZnojEnk5FE8SiUTNn0AvvTGpw@mail.gmail.com>
Message-ID: <0D54576F-4C48-4CFB-A208-D74859BC939B@astro.princeton.edu>

> BTW, Python can just call all those fancy C++ routines and provide wrappers. 

We're calling it all from python, using swig.  That's not the problem; the problem is convincing people to install quite a deep software stack (and providing documentation now, when there's not a lot of money or people).

> At the same time, I wonder if that LSST software can be used freely or will have export restrictions ? 

And all the code's on github, under the GPL (v3).

						R



From npkuin at gmail.com  Tue May 28 16:57:23 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Tue, 28 May 2013 21:57:23 +0100
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
In-Reply-To: <0D54576F-4C48-4CFB-A208-D74859BC939B@astro.princeton.edu>
References: <mailman.1.1369760402.7575.astropy@scipy.org>
	<54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
	<CANoQ6N12RSkQX__=HAWdJ2f6RZnojEnk5FE8SiUTNn0AvvTGpw@mail.gmail.com>
	<0D54576F-4C48-4CFB-A208-D74859BC939B@astro.princeton.edu>
Message-ID: <CANoQ6N0D=Evpqq_Fz1Y+HOH+u_K0-QJa2CagA7c+hVueS_Z_Qw@mail.gmail.com>

Wow!


On Tue, May 28, 2013 at 9:56 PM, Robert Lupton the Good <
rhl at astro.princeton.edu> wrote:

> > BTW, Python can just call all those fancy C++ routines and provide
> wrappers.
>
> We're calling it all from python, using swig.  That's not the problem; the
> problem is convincing people to install quite a deep software stack (and
> providing documentation now, when there's not a lot of money or people).
>
> > At the same time, I wonder if that LSST software can be used freely or
> will have export restrictions ?
>
> And all the code's on github, under the GPL (v3).
>
>                                                 R
>
>


-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204927 (work) -276110 (home)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130528/b3841d4c/attachment.html>

From mjuric at lsst.org  Tue May 28 23:33:00 2013
From: mjuric at lsst.org (Mario Juric)
Date: Tue, 28 May 2013 20:33:00 -0700
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
In-Reply-To: <0D54576F-4C48-4CFB-A208-D74859BC939B@astro.princeton.edu>
References: <mailman.1.1369760402.7575.astropy@scipy.org>
	<54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
	<CANoQ6N12RSkQX__=HAWdJ2f6RZnojEnk5FE8SiUTNn0AvvTGpw@mail.gmail.com>
	<0D54576F-4C48-4CFB-A208-D74859BC939B@astro.princeton.edu>
Message-ID: <51A576EC.2060509@lsst.org>

On 5/28/13 13:56 , Robert Lupton the Good wrote:
>> BTW, Python can just call all those fancy C++ routines and provide wrappers. 
> 
> We're calling it all from python, using swig.  That's not the
> problem; the problem is convincing people to install quite a deep
> software stack (and providing documentation now, when there's not a
> lot of money or people).
> 
>> At the same time, I wonder if that LSST software can be used freely
>> or will have export restrictions ?
> 
> And all the code's on github, under the GPL (v3).
> 

Not quite on github (yet), but under git:

	https://dev.lsstcorp.org/cgit/

. However, anyone tempted to jump in should first read:

	https://dev.lsstcorp.org/trac/wiki/DM/Policy/UsingDMCode/FAQ

And an overview presentation can be found at http://ls.st/e12 .

As Robert said, right now we're under-resourced and swamped with reviews
and preps for start of LSST construction. But looking beyond the next
few months, we're generally very interested in opening up the LSST
codebase and development, to ensure it's as useful to the community as
possible.

Cheers,
-- 
Mario Juric,
Data Mgmt. Project Scientist, Large Synoptic Survey Telescope
Web   :  http://www.cfa.harvard.edu/~mjuric/
Phone :  +1 617 744 9003       PGP: ~mjuric/crypto/public.key


From astropy at liska.ath.cx  Wed May 29 03:18:50 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Wed, 29 May 2013 09:18:50 +0200
Subject: [AstroPy] AstroPy Digest, Vol 80, Issue 16
References: <mailman.1.1369760402.7575.astropy@scipy.org>
	<54096F2D-5322-42F0-AA48-7E48CE26671D@astro.princeton.edu>
	<CANoQ6N12RSkQX__=HAWdJ2f6RZnojEnk5FE8SiUTNn0AvvTGpw@mail.gmail.com>
	<0D54576F-4C48-4CFB-A208-D74859BC939B@astro.princeton.edu>
Message-ID: <ytzd2sa45k5.fsf@news.ole.ath.cx>

Robert Lupton the Good <rhl at astro.princeton.edu> writes:
> the problem is convincing people to install quite a deep software
> stack (and providing documentation now, when there's not a lot of
> money or people).

I would recommend to package the software and upload them to the major
Linux distributions (I'd advocating Debian, but Fedora is an option as
well). The advantage is that the package manager will automatically
solve all the deep dependencies when one installs that one package that
(s)he wants to work with.

It is some work, but it greatly improves the visibility of the software.

> And all the code's on github, under the GPL (v3).

This makes it OK to be included in Debian resp. Fedora. Official
releases with tar files are even better :-)

Best regards

Ole

P.S. I don't have the ressources to package it for Debian myself, but I
can provide some help, if needed.