From jturner at gemini.edu  Tue Apr  2 14:37:43 2013
From: jturner at gemini.edu (James Turner)
Date: Tue, 2 Apr 2013 14:37:43 -0400
Subject: [AstroPy] SciPy 2013
Message-ID: <515B2577.4080505@gemini.edu>

So who's finally going to SciPy? I believe the extended abstract
deadline is tomorrow. I'm still leaning towards going and had
better write one :-). Anyone planning on staying for sprints?
Any plans for an AstroPy meeting this year?

Cheers,

James.


From eebanado at uc.cl  Wed Apr  3 10:30:55 2013
From: eebanado at uc.cl (=?ISO-8859-1?Q?Eduardo_Ba=F1ados_Torres?=)
Date: Wed, 3 Apr 2013 16:30:55 +0200
Subject: [AstroPy] appending Tables in Astropy
Message-ID: <CAE_d_sAjKNZgOhmBpSyprWpFEJFJ+0s97K9ho0uugxMGC+KgLA@mail.gmail.com>

Hi all,

I am missing an 'append' method in the astropy Table object  as it exists
in ATpy: http://atpy.github.com/manipulating.html#combining-tables

Does it exist within astropy something to combine two tables (or more) that
have the same columns?

Cheers,

-- 
Eduardo Ba?ados
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130403/c9daf1e7/attachment.html>

From aldcroft at head.cfa.harvard.edu  Wed Apr  3 11:53:34 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Wed, 3 Apr 2013 11:53:34 -0400
Subject: [AstroPy] appending Tables in Astropy
In-Reply-To: <CAE_d_sAjKNZgOhmBpSyprWpFEJFJ+0s97K9ho0uugxMGC+KgLA@mail.gmail.com>
References: <CAE_d_sAjKNZgOhmBpSyprWpFEJFJ+0s97K9ho0uugxMGC+KgLA@mail.gmail.com>
Message-ID: <CAGsQ-NtRy2-yizsuAPqim2oAnjo0q+Qx7hocQUH1VY9iTJpM+Q@mail.gmail.com>

Good timing.  This is a pending pull request (see link).  The astropy
Table object should have this functionality in the dev version within
a week or so, barring any issues that show up in review.

https://github.com/astropy/astropy/pull/937

Cheers,
Tom

On Wed, Apr 3, 2013 at 10:30 AM, Eduardo Ba?ados Torres <eebanado at uc.cl> wrote:
> Hi all,
>
> I am missing an 'append' method in the astropy Table object  as it exists in
> ATpy: http://atpy.github.com/manipulating.html#combining-tables
>
> Does it exist within astropy something to combine two tables (or more) that
> have the same columns?
>
> Cheers,
>
> --
> Eduardo Ba?ados
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From erik.tollerud at gmail.com  Wed Apr  3 20:18:45 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 3 Apr 2013 20:18:45 -0400
Subject: [AstroPy] ANN: Astropy 0.2.1 released
Message-ID: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>

Dear colleagues,

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

v0.2.1 is a bug fix release.  Of particular note is that some
installation issues reported in v0.2 have been addressed.  Hence, if
you encountered installation problems with v0.2 you may want to try
again with v0.2.1.  The full list of  changes can be found at
http://docs.astropy.org/en/v0.2.1/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.1


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


From bkloppenborg at gmail.com  Thu Apr  4 04:58:37 2013
From: bkloppenborg at gmail.com (Brian Kloppenborg)
Date: Thu, 04 Apr 2013 10:58:37 +0200
Subject: [AstroPy] Support for OIFITS, reconstructed images
In-Reply-To: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
References: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
Message-ID: <515D40BD.1080701@gmail.com>

Greetings,

I do optical/NIR interferometric image reconstruction. I have two
questions relating to how I should get some of our needs supported in
AstroPy:

First, the data from our instruments comes in an IAU-sanctioned
extension of the FITS data format called OIFITS (
http://www.mrao.cam.ac.uk/projects/OAS/oi_data/oifits.html). There is a
standard C library (which uses CFITSIO) for reading/writing these files,
but it is very non-pythonic. What would be the best way get support for
OIFITS into the AstroPy framework? Should I write something from scratch
using astropy.io.fits (I've already written a new C++ library on top of
CCFITS, which addresses several inconvenient CFITSIO access methods) or
integrate a SWIG/CLANG wrapper over the existing C-based OIFITSLIB?

Second, our image reconstruction methods produce FITS images that are a
few milliarcseconds across (our highest formal angular resolution is
~0.3 mas, but we reconstruct with pixels that are ~10x smaller), but do
not have any good coordinate information. All we know with confidence is
the size of a pixel (we define it); North is up, and East is to the
left. What information should we store within the images to make their
use within AstroPy/APLpy easier?

Kind regards,
Brian Kloppenborg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130404/35ccb455/attachment.html>

From perry at stsci.edu  Thu Apr  4 07:59:40 2013
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 4 Apr 2013 07:59:40 -0400
Subject: [AstroPy] Support for OIFITS, reconstructed images
In-Reply-To: <515D40BD.1080701@gmail.com>
References: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
	<515D40BD.1080701@gmail.com>
Message-ID: <5D6EA0B0-357E-49C8-84F6-3DBC1F206AC1@stsci.edu>


On Apr 4, 2013, at 4:58 AM, Brian Kloppenborg wrote:
> 
> I do optical/NIR interferometric image reconstruction. I have two questions relating to how I should get some of our needs supported in AstroPy:
> 
> First, the data from our instruments comes in an IAU-sanctioned extension of the FITS data format called OIFITS ( http://www.mrao.cam.ac.uk/projects/OAS/oi_data/oifits.html). There is a standard C library (which uses CFITSIO) for reading/writing these files, but it is very non-pythonic. What would be the best way get support for OIFITS into the AstroPy framework? Should I write something from scratch using astropy.io.fits (I've already written a new C++ library on top of CCFITS, which addresses several inconvenient CFITSIO access methods) or integrate a SWIG/CLANG wrapper over the existing C-based OIFITSLIB?
> 
> Second, our image reconstruction methods produce FITS images that are a few milliarcseconds across (our highest formal angular resolution is ~0.3 mas, but we reconstruct with pixels that are ~10x smaller), but do not have any good coordinate information. All we know with confidence is the size of a pixel (we define it); North is up, and East is to the left. What information should we store within the images to make their use within AstroPy/APLpy easier?

Before that can be answered well, it needs to be outlined what such support of this convention entails (to be clear, it's not an IAU standard, but only a registered convention as far I see from the link you provided). Presumably the astropy.io.fits can read these files already, so I'm guessing you want a more convenient object returned than the usual FITS structures (there isn't any new kind of extension, is there?). If that's the case, the people who use these objects should be the ones to design them. Are you asking us to implement this, or are you asking how to add your code to astropy? (You can infer that I'd prefer the latter; most of the existing contributors have higher priorities for development.). I'd say that coming up with working code in Python that does this is the first step, and to make that code compatible with the astropy guidelines for coding style, dependencies, tests, and documentation. Eventually this would result in a pull request to have it merged into the astropy core if it seemed to have good support in the relevant community.

If you have questions about the best way to do the implementation, I think the astropy-dev mailing list is a good place to start.

Cheers, Perry



From bkloppenborg at gmail.com  Thu Apr  4 09:58:05 2013
From: bkloppenborg at gmail.com (Brian Kloppenborg)
Date: Thu, 04 Apr 2013 15:58:05 +0200
Subject: [AstroPy] Support for OIFITS, reconstructed images
In-Reply-To: <5D6EA0B0-357E-49C8-84F6-3DBC1F206AC1@stsci.edu>
References: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
	<515D40BD.1080701@gmail.com>
	<5D6EA0B0-357E-49C8-84F6-3DBC1F206AC1@stsci.edu>
Message-ID: <515D86ED.9090201@gmail.com>

Hi Perry,

On 04/04/2013 01:59 PM, Perry Greenfield wrote:
> Before that can be answered well, it needs to be outlined what such
> support of this convention entails (to be clear, it's not an IAU
> standard, but only a registered convention as far I see from the link
> you provided). 
Indeed, although developed under the auspice of IAU working group 54 it
is just a registered FITS convention:
http://fits.gsfc.nasa.gov/registry/oifits.html
> Presumably the astropy.io.fits can read these files already, so I'm
> guessing you want a more convenient object returned than the usual
> FITS structures (there isn't any new kind of extension, is there?). If
> that's the case, the people who use these objects should be the ones
> to design them. Are you asking us to implement this, or are you asking
> how to add your code to astropy? (You can infer that I'd prefer the
> latter; most of the existing contributors have higher priorities for
> development.). 
Indeed, astropy.io.fits can read and write these files already, I would
like to see a more convenient interface to OIFITS files merged into the
AstroPy library. This is something that I would do, rather than asking
other developers. The process by which this is done (which you explain
below) is what I was after.

> I'd say that coming up with working code in Python that does this is
> the first step, and to make that code compatible with the astropy
> guidelines for coding style, dependencies, tests, and documentation.
> Eventually this would result in a pull request to have it merged into
> the astropy core if it seemed to have good support in the relevant
> community. If you have questions about the best way to do the
> implementation, I think the astropy-dev mailing list is a good place
> to start.
Thanks. I'll check out these documents and get coding. I'll take the
SWIG/Clang question to them as well.

Cheers,
Brian


From thomas.robitaille at gmail.com  Thu Apr  4 10:08:01 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 4 Apr 2013 16:08:01 +0200
Subject: [AstroPy] Support for OIFITS, reconstructed images
In-Reply-To: <515D86ED.9090201@gmail.com>
References: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
	<515D40BD.1080701@gmail.com>
	<5D6EA0B0-357E-49C8-84F6-3DBC1F206AC1@stsci.edu>
	<515D86ED.9090201@gmail.com>
Message-ID: <CAGMHX_15WP8tZDdwbx0V=BMi_383_xfxwv5=30ycZ2SU8H5f-g@mail.gmail.com>

I am not familiar with the OIFITS standard, but if the contents can
basically be represented by a sub-class of a Table or NDData object,
you could develop that sub-class, then add a reader/writer for that
sub-class using the existing I/O infrastructure:

http://docs.astropy.org/en/v0.2.1/io/registry.html

Then you could do e.g.

f = OIFITS.read('some_oifits_file.fits')

Cheers,
Tom


On 4 April 2013 15:58, Brian Kloppenborg <bkloppenborg at gmail.com> wrote:
> Hi Perry,
>
> On 04/04/2013 01:59 PM, Perry Greenfield wrote:
>> Before that can be answered well, it needs to be outlined what such
>> support of this convention entails (to be clear, it's not an IAU
>> standard, but only a registered convention as far I see from the link
>> you provided).
> Indeed, although developed under the auspice of IAU working group 54 it
> is just a registered FITS convention:
> http://fits.gsfc.nasa.gov/registry/oifits.html
>> Presumably the astropy.io.fits can read these files already, so I'm
>> guessing you want a more convenient object returned than the usual
>> FITS structures (there isn't any new kind of extension, is there?). If
>> that's the case, the people who use these objects should be the ones
>> to design them. Are you asking us to implement this, or are you asking
>> how to add your code to astropy? (You can infer that I'd prefer the
>> latter; most of the existing contributors have higher priorities for
>> development.).
> Indeed, astropy.io.fits can read and write these files already, I would
> like to see a more convenient interface to OIFITS files merged into the
> AstroPy library. This is something that I would do, rather than asking
> other developers. The process by which this is done (which you explain
> below) is what I was after.
>
>> I'd say that coming up with working code in Python that does this is
>> the first step, and to make that code compatible with the astropy
>> guidelines for coding style, dependencies, tests, and documentation.
>> Eventually this would result in a pull request to have it merged into
>> the astropy core if it seemed to have good support in the relevant
>> community. If you have questions about the best way to do the
>> implementation, I think the astropy-dev mailing list is a good place
>> to start.
> Thanks. I'll check out these documents and get coding. I'll take the
> SWIG/Clang question to them as well.
>
> Cheers,
> Brian
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From perry at stsci.edu  Thu Apr  4 10:21:42 2013
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 4 Apr 2013 10:21:42 -0400
Subject: [AstroPy] Support for OIFITS, reconstructed images
In-Reply-To: <CAGMHX_15WP8tZDdwbx0V=BMi_383_xfxwv5=30ycZ2SU8H5f-g@mail.gmail.com>
References: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
	<515D40BD.1080701@gmail.com>
	<5D6EA0B0-357E-49C8-84F6-3DBC1F206AC1@stsci.edu>
	<515D86ED.9090201@gmail.com>
	<CAGMHX_15WP8tZDdwbx0V=BMi_383_xfxwv5=30ycZ2SU8H5f-g@mail.gmail.com>
Message-ID: <629CBF76-5A72-4C2B-A50C-21613CF1D0EE@stsci.edu>

I think it is mostly visibility data which doesn't fit an image model very well. It's possible that some sort of table could handle it though. They may want a table that supports operations that are usually done with visibility data so that may mean a significant amount of customization of tables.

Perry

On Apr 4, 2013, at 10:08 AM, Thomas Robitaille wrote:

> I am not familiar with the OIFITS standard, but if the contents can
> basically be represented by a sub-class of a Table or NDData object,
> you could develop that sub-class, then add a reader/writer for that
> sub-class using the existing I/O infrastructure:
> 
> http://docs.astropy.org/en/v0.2.1/io/registry.html
> 
> Then you could do e.g.
> 
> f = OIFITS.read('some_oifits_file.fits')
> 
> Cheers,
> Tom
> 
> 
> On 4 April 2013 15:58, Brian Kloppenborg <bkloppenborg at gmail.com> wrote:
>> Hi Perry,
>> 
>> On 04/04/2013 01:59 PM, Perry Greenfield wrote:
>>> Before that can be answered well, it needs to be outlined what such
>>> support of this convention entails (to be clear, it's not an IAU
>>> standard, but only a registered convention as far I see from the link
>>> you provided).
>> Indeed, although developed under the auspice of IAU working group 54 it
>> is just a registered FITS convention:
>> http://fits.gsfc.nasa.gov/registry/oifits.html
>>> Presumably the astropy.io.fits can read these files already, so I'm
>>> guessing you want a more convenient object returned than the usual
>>> FITS structures (there isn't any new kind of extension, is there?). If
>>> that's the case, the people who use these objects should be the ones
>>> to design them. Are you asking us to implement this, or are you asking
>>> how to add your code to astropy? (You can infer that I'd prefer the
>>> latter; most of the existing contributors have higher priorities for
>>> development.).
>> Indeed, astropy.io.fits can read and write these files already, I would
>> like to see a more convenient interface to OIFITS files merged into the
>> AstroPy library. This is something that I would do, rather than asking
>> other developers. The process by which this is done (which you explain
>> below) is what I was after.
>> 
>>> I'd say that coming up with working code in Python that does this is
>>> the first step, and to make that code compatible with the astropy
>>> guidelines for coding style, dependencies, tests, and documentation.
>>> Eventually this would result in a pull request to have it merged into
>>> the astropy core if it seemed to have good support in the relevant
>>> community. If you have questions about the best way to do the
>>> implementation, I think the astropy-dev mailing list is a good place
>>> to start.
>> Thanks. I'll check out these documents and get coding. I'll take the
>> SWIG/Clang question to them as well.
>> 
>> Cheers,
>> Brian
>> _______________________________________________
>> 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 bkloppenborg at gmail.com  Thu Apr  4 10:50:08 2013
From: bkloppenborg at gmail.com (Brian Kloppenborg)
Date: Thu, 04 Apr 2013 16:50:08 +0200
Subject: [AstroPy] Support for OIFITS, reconstructed images
In-Reply-To: <629CBF76-5A72-4C2B-A50C-21613CF1D0EE@stsci.edu>
References: <CAARXUwUnY7O2w76Gz5F=ogAHz=VLKC6GqQxk31CbDUhfZG87Hw@mail.gmail.com>
	<515D40BD.1080701@gmail.com>
	<5D6EA0B0-357E-49C8-84F6-3DBC1F206AC1@stsci.edu>
	<515D86ED.9090201@gmail.com>
	<CAGMHX_15WP8tZDdwbx0V=BMi_383_xfxwv5=30ycZ2SU8H5f-g@mail.gmail.com>
	<629CBF76-5A72-4C2B-A50C-21613CF1D0EE@stsci.edu>
Message-ID: <515D9320.5090007@gmail.com>

At present the OIFITS data format is for storing binary tabular data.
Internally, the data is like a normalized database, so unpacking it to a
single table would result much duplication of data. Today files are
fairly small (< 1MB), so even a 10x increase in size wouldn't be a big
deal, but this will change in the next few years.

My C++ library keeps everything compact and lets the user
filter/merge/sort on OI_DATA objects (stores pointers to duplicated data
quantities), then export to tabular data once they are done. Something
similar to this could be implemented fairly easily in AstroPy. (My
library uses CCFITS and CFITSIO, so simply SWIG/CYTHON-ing the library
probably isn't an option, unless AstroPy wants to distributed those
libraries too.)

Cheers,
Brian

On 04/04/2013 04:21 PM, Perry Greenfield wrote:
> I think it is mostly visibility data which doesn't fit an image model very well. It's possible that some sort of table could handle it though. They may want a table that supports operations that are usually done with visibility data so that may mean a significant amount of customization of tables.


>
> Perry
>
> On Apr 4, 2013, at 10:08 AM, Thomas Robitaille wrote:
>
>> I am not familiar with the OIFITS standard, but if the contents can
>> basically be represented by a sub-class of a Table or NDData object,
>> you could develop that sub-class, then add a reader/writer for that
>> sub-class using the existing I/O infrastructure:
>>
>> http://docs.astropy.org/en/v0.2.1/io/registry.html
>>
>> Then you could do e.g.
>>
>> f = OIFITS.read('some_oifits_file.fits')
>>
>> Cheers,
>> Tom
>>
>>
>> On 4 April 2013 15:58, Brian Kloppenborg <bkloppenborg at gmail.com> wrote:
>>> Hi Perry,
>>>
>>> On 04/04/2013 01:59 PM, Perry Greenfield wrote:
>>>> Before that can be answered well, it needs to be outlined what such
>>>> support of this convention entails (to be clear, it's not an IAU
>>>> standard, but only a registered convention as far I see from the link
>>>> you provided).
>>> Indeed, although developed under the auspice of IAU working group 54 it
>>> is just a registered FITS convention:
>>> http://fits.gsfc.nasa.gov/registry/oifits.html
>>>> Presumably the astropy.io.fits can read these files already, so I'm
>>>> guessing you want a more convenient object returned than the usual
>>>> FITS structures (there isn't any new kind of extension, is there?). If
>>>> that's the case, the people who use these objects should be the ones
>>>> to design them. Are you asking us to implement this, or are you asking
>>>> how to add your code to astropy? (You can infer that I'd prefer the
>>>> latter; most of the existing contributors have higher priorities for
>>>> development.).
>>> Indeed, astropy.io.fits can read and write these files already, I would
>>> like to see a more convenient interface to OIFITS files merged into the
>>> AstroPy library. This is something that I would do, rather than asking
>>> other developers. The process by which this is done (which you explain
>>> below) is what I was after.
>>>
>>>> I'd say that coming up with working code in Python that does this is
>>>> the first step, and to make that code compatible with the astropy
>>>> guidelines for coding style, dependencies, tests, and documentation.
>>>> Eventually this would result in a pull request to have it merged into
>>>> the astropy core if it seemed to have good support in the relevant
>>>> community. If you have questions about the best way to do the
>>>> implementation, I think the astropy-dev mailing list is a good place
>>>> to start.
>>> Thanks. I'll check out these documents and get coding. I'll take the
>>> SWIG/Clang question to them as well.
>>>
>>> Cheers,
>>> Brian
>>> _______________________________________________
>>> 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 lsinger at caltech.edu  Sun Apr  7 16:07:18 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Sun, 7 Apr 2013 13:07:18 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
Message-ID: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>

Hello,

I would like to use Astropy on Debian and Scientific Linux. My experiment is pretty strict about using packaged software. Are there are there any plans to create .debs or .rpms for Astropy?

I know how to create packages for both platforms, so I could help, but I don't (yet) know much about how the Debian and Scientific Linux/Red Hat/Fedora communities work, so I would not yet know where or how to submit them.

Best,
Leo Singer
Graduate Student @ LIGO-Caltech


From jzuhone at gmail.com  Sun Apr  7 16:37:54 2013
From: jzuhone at gmail.com (John ZuHone)
Date: Sun, 7 Apr 2013 16:37:54 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
Message-ID: <9DA533E3-2947-4936-9618-2A2C882F7390@gmail.com>

Hi Leo,

I'd try pip: https://pypi.python.org/pypi/pip

You can look for Debian and Scientific Linux packages for pip online. 

Then you run

pip install astropy  

from the terminal.

This is essentially the "python way" of installing packages.

Sorry, I'm in a bit of a rush, but if you need more info please email back.

Best,

John Z

On Apr 7, 2013, at 4:07 PM, Leo Singer <lsinger at caltech.edu> wrote:

> Hello,
> 
> I would like to use Astropy on Debian and Scientific Linux. My experiment is pretty strict about using packaged software. Are there are there any plans to create .debs or .rpms for Astropy?
> 
> I know how to create packages for both platforms, so I could help, but I don't (yet) know much about how the Debian and Scientific Linux/Red Hat/Fedora communities work, so I would not yet know where or how to submit them.
> 
> Best,
> Leo Singer
> Graduate Student @ LIGO-Caltech
> _______________________________________________
> 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/20130407/a2a9cfd9/attachment.html>

From sergio.pasra at gmail.com  Sun Apr  7 17:50:22 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Sun, 7 Apr 2013 23:50:22 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
Message-ID: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>

Hi,

the past year we had a discussion about SOFA, an IAU library astropy
depends on, see the details here:
https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion

In short:

 * The Fedora legal team reviewed the SOFA license and they considered it
non-free.
 * I wrote the SOFA board asking for a license change, they did not
answered my request
 * SOFA and (any program depending on it) *astropy* cannot be included in
Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA
license.
 * astropy could be included by *removing* SOFA and the modules depending
on it (astropy.time ?)
 * somebody could package SOFA and astropy in rpmfusion.org, which provides
non-free/free-with-legal-problems packages for Fedora and EPEL
 * or in a different Fedora repository that provides
 * I think the situation in Debian is different

Not having precompiled packages available in Fedora/EPEL is very bad for
astropy in my opinion. From a small sample of 20
Professors-Postdocs-Students in my Astrophysics Department, I can say that
only those doing software development use "pip". The vast majority use
"yum" in Fedora or "fink/macports" in Mac to bring in the package and
continue doing Science.

Regards, Sergio



2013/4/7 Leo Singer <lsinger at caltech.edu>

> Hello,
>
> I would like to use Astropy on Debian and Scientific Linux. My experiment
> is pretty strict about using packaged software. Are there are there any
> plans to create .debs or .rpms for Astropy?
>
> I know how to create packages for both platforms, so I could help, but I
> don't (yet) know much about how the Debian and Scientific Linux/Red
> Hat/Fedora communities work, so I would not yet know where or how to submit
> them.
>
> Best,
> Leo Singer
> Graduate Student @ LIGO-Caltech
> _______________________________________________
> 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/20130407/63b6a2a4/attachment.html>

From jzuhone at gmail.com  Sun Apr  7 18:10:51 2013
From: jzuhone at gmail.com (John Zuhone)
Date: Sun, 07 Apr 2013 15:10:51 -0700 (PDT)
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
References: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
Message-ID: <1365372650840.085bd476@Nodemailer>

Sergio,


I have no idea what you are talking about when you insinuate that using pip is a roadblock to getting on with "Science."?


You don't have to download or compile any source code at all to use pip. Once installed (from yum or something else), it works just like any other package manager.


Best,


John Z
?
Sent from Mailbox for iPhone

On Sun, Apr 7, 2013 at 5:50 PM, Sergio Pascual <sergio.pasra at gmail.com>
wrote:

> Hi,
> the past year we had a discussion about SOFA, an IAU library astropy
> depends on, see the details here:
> https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
> In short:
>  * The Fedora legal team reviewed the SOFA license and they considered it
> non-free.
>  * I wrote the SOFA board asking for a license change, they did not
> answered my request
>  * SOFA and (any program depending on it) *astropy* cannot be included in
> Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA
> license.
>  * astropy could be included by *removing* SOFA and the modules depending
> on it (astropy.time ?)
>  * somebody could package SOFA and astropy in rpmfusion.org, which provides
> non-free/free-with-legal-problems packages for Fedora and EPEL
>  * or in a different Fedora repository that provides
>  * I think the situation in Debian is different
> Not having precompiled packages available in Fedora/EPEL is very bad for
> astropy in my opinion. From a small sample of 20
> Professors-Postdocs-Students in my Astrophysics Department, I can say that
> only those doing software development use "pip". The vast majority use
> "yum" in Fedora or "fink/macports" in Mac to bring in the package and
> continue doing Science.
> Regards, Sergio
> 2013/4/7 Leo Singer <lsinger at caltech.edu>
>> Hello,
>>
>> I would like to use Astropy on Debian and Scientific Linux. My experiment
>> is pretty strict about using packaged software. Are there are there any
>> plans to create .debs or .rpms for Astropy?
>>
>> I know how to create packages for both platforms, so I could help, but I
>> don't (yet) know much about how the Debian and Scientific Linux/Red
>> Hat/Fedora communities work, so I would not yet know where or how to submit
>> them.
>>
>> Best,
>> Leo Singer
>> Graduate Student @ LIGO-Caltech
>> _______________________________________________
>> 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/20130407/8b0815cf/attachment.html>

From sergio.pasra at gmail.com  Sun Apr  7 19:17:50 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Mon, 8 Apr 2013 01:17:50 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <1365372650840.085bd476@Nodemailer>
References: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<1365372650840.085bd476@Nodemailer>
Message-ID: <CACta-KYby5XWToik6p4co+k2s1Tq7wttEkbejefhd5kQdApn0Q@mail.gmail.com>

Disclaimer: I'm a packager in Fedora Linux

John,

pip will download the tarballs of python packages and compile them using
the available tools in the system. That works well for pure Python
 packages, but once you start with packages with C dependencies things grow
fragile. For example, pip won't install the ATLAS libraries if you don't
have them and you are trying to build numpy. Other packages such as scipy
and matplotlib are difficult to build properly using pip unless you know
what you are doing.

So, in my opinion, a precompiled package is much better solution for a
casual user, someone that wants to write a short script and get a plot
quickly.

Unless, of course, you don't have root access.

Regards



2013/4/8 John Zuhone <jzuhone at gmail.com>

> Sergio,
>
> I have no idea what you are talking about when you insinuate that using
> pip is a roadblock to getting on with "Science."
>
> You don't have to download or compile any source code at all to use pip.
> Once installed (from yum or something else), it works just like any other
> package manager.
>
> Best,
>
> John Z
> ?
> Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone
>
>
> On Sun, Apr 7, 2013 at 5:50 PM, Sergio Pascual <sergio.pasra at gmail.com>wrote:
>
>> Hi,
>>
>> the past year we had a discussion about SOFA, an IAU library astropy
>> depends on, see the details here:
>> https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
>>
>> In short:
>>
>>   * The Fedora legal team reviewed the SOFA license and they considered
>> it non-free.
>>  * I wrote the SOFA board asking for a license change, they did not
>> answered my request
>>  * SOFA and (any program depending on it) *astropy* cannot be included in
>> Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA
>> license.
>>  * astropy could be included by *removing* SOFA and the modules depending
>> on it (astropy.time ?)
>>  * somebody could package SOFA and astropy in rpmfusion.org, which
>> provides non-free/free-with-legal-problems packages for Fedora and EPEL
>>  * or in a different Fedora repository that provides
>>  * I think the situation in Debian is different
>>
>> Not having precompiled packages available in Fedora/EPEL is very bad for
>> astropy in my opinion. From a small sample of 20
>> Professors-Postdocs-Students in my Astrophysics Department, I can say that
>> only those doing software development use "pip". The vast majority use
>> "yum" in Fedora or "fink/macports" in Mac to bring in the package and
>> continue doing Science.
>>
>> Regards, Sergio
>>
>>
>>
>> 2013/4/7 Leo Singer <lsinger at caltech.edu>
>>
>>> Hello,
>>>
>>> I would like to use Astropy on Debian and Scientific Linux. My
>>> experiment is pretty strict about using packaged software. Are there are
>>> there any plans to create .debs or .rpms for Astropy?
>>>
>>> I know how to create packages for both platforms, so I could help, but I
>>> don't (yet) know much about how the Debian and Scientific Linux/Red
>>> Hat/Fedora communities work, so I would not yet know where or how to submit
>>> them.
>>>
>>> Best,
>>> Leo Singer
>>> Graduate Student @ LIGO-Caltech
>>> _______________________________________________
>>> 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/20130408/5dac10b2/attachment.html>

From lsinger at caltech.edu  Sun Apr  7 20:12:36 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Sun, 7 Apr 2013 17:12:36 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <9DA533E3-2947-4936-9618-2A2C882F7390@gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<9DA533E3-2947-4936-9618-2A2C882F7390@gmail.com>
Message-ID: <C760638F-A10B-4E6C-9733-A78D3311F93C@caltech.edu>

On Apr 7, 2013, at 1:37 PM, John ZuHone <jzuhone at gmail.com> wrote:

> I'd try pip: https://pypi.python.org/pypi/pip
> 
> You can look for Debian and Scientific Linux packages for pip online. 
> 
> Then you run
> 
> pip install astropy  
> 
> from the terminal.
> 
> This is essentially the "python way" of installing packages.

John,

Thank you; pip would work except that we need packages that can be installed with apt or yum. Our lab insists on it; the policy must be due to how they manage our computing clusters.

Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130407/17687d4e/attachment.html>

From lsinger at caltech.edu  Sun Apr  7 20:18:37 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Sun, 7 Apr 2013 17:18:37 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
Message-ID: <1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu>

On Apr 7, 2013, at 2:50 PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:

> the past year we had a discussion about SOFA, an IAU library astropy depends on, see the details here:
> https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
> 
> In short:
> 
>  * The Fedora legal team reviewed the SOFA license and they considered it non-free.
>  * I wrote the SOFA board asking for a license change, they did not answered my request 
>  * SOFA and (any program depending on it) *astropy* cannot be included in Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA license.
>  * astropy could be included by *removing* SOFA and the modules depending on it (astropy.time ?)
>  * somebody could package SOFA and astropy in rpmfusion.org, which provides non-free/free-with-legal-problems packages for Fedora and EPEL
>  * or in a different Fedora repository that provides 
>  * I think the situation in Debian is different
> 
> Not having precompiled packages available in Fedora/EPEL is very bad for astropy in my opinion. From a small sample of 20 Professors-Postdocs-Students in my Astrophysics Department, I can say that only those doing software development use "pip". The vast majority use "yum" in Fedora or "fink/macports" in Mac to bring in the package and continue doing Science.


Wow, the SOFA license **is** pretty strange. What a shame.

Could you get the time conversion functions that you need from NOVAS (http://aa.usno.navy.mil/software/novas/novas_c/novasc_info.php)? Although you would want to contact its maintainers to check, I think that NOVAS is not just free, it's actually in the public domain.

Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130407/49fdac12/attachment.html>

From aldcroft at head.cfa.harvard.edu  Sun Apr  7 20:22:24 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Sun, 7 Apr 2013 20:22:24 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
Message-ID: <CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>

On Sun, Apr 7, 2013 at 5:50 PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:
> Hi,
>
> the past year we had a discussion about SOFA, an IAU library astropy depends
> on, see the details here:
> https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
>
> In short:
>
>  * The Fedora legal team reviewed the SOFA license and they considered it
> non-free.
>  * I wrote the SOFA board asking for a license change, they did not answered
> my request
>  * SOFA and (any program depending on it) *astropy* cannot be included in
> Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA
> license.
>  * astropy could be included by *removing* SOFA and the modules depending on
> it (astropy.time ?)
>  * somebody could package SOFA and astropy in rpmfusion.org, which provides
> non-free/free-with-legal-problems packages for Fedora and EPEL
>  * or in a different Fedora repository that provides
>  * I think the situation in Debian is different

Sergio,

I wonder if it might be worth trying again with SOFA.  Things are a
little different now since at this point there are real users that are
unable to use our (and their) software because of their license.  This
is very frustrating.

I wonder if we could organize a petition in support of modifying the
SOFA license to something more consistent with typical community
standards.  I mean the IAU is supposed to be representing and
benefiting astronomers, no?

Thanks,
Tom

>
> Not having precompiled packages available in Fedora/EPEL is very bad for
> astropy in my opinion. From a small sample of 20
> Professors-Postdocs-Students in my Astrophysics Department, I can say that
> only those doing software development use "pip". The vast majority use "yum"
> in Fedora or "fink/macports" in Mac to bring in the package and continue
> doing Science.
>
> Regards, Sergio
>
>
>
> 2013/4/7 Leo Singer <lsinger at caltech.edu>
>>
>> Hello,
>>
>> I would like to use Astropy on Debian and Scientific Linux. My experiment
>> is pretty strict about using packaged software. Are there are there any
>> plans to create .debs or .rpms for Astropy?
>>
>> I know how to create packages for both platforms, so I could help, but I
>> don't (yet) know much about how the Debian and Scientific Linux/Red
>> Hat/Fedora communities work, so I would not yet know where or how to submit
>> them.
>>
>> Best,
>> Leo Singer
>> Graduate Student @ LIGO-Caltech
>> _______________________________________________
>> 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 jeremy.s.perkins at nasa.gov  Sun Apr  7 20:33:02 2013
From: jeremy.s.perkins at nasa.gov (Jeremy Perkins)
Date: Sun, 7 Apr 2013 20:33:02 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <C760638F-A10B-4E6C-9733-A78D3311F93C@caltech.edu>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<9DA533E3-2947-4936-9618-2A2C882F7390@gmail.com>
	<C760638F-A10B-4E6C-9733-A78D3311F93C@caltech.edu>
Message-ID: <C72DED01-1FB6-465E-BC28-21FEE82A1AB2@nasa.gov>

Hi Leo,

You can set up pip to install packages to a user-defined location that you add to your python-path.  This could even be in your home directory (like ~/python or ~/.python).  This way you don't have to have root access or install them globally.  That's what I usually do when I'm working on a system that's locked down.

Jeremy

On Apr 7, 2013, at 8:12 PM, Leo Singer <lsinger at caltech.edu> wrote:

> John,
> 
> Thank you; pip would work except that we need packages that can be installed with apt or yum. Our lab insists on it; the policy must be due to how they manage our computing clusters.
> 
> Leo



From lsinger at caltech.edu  Sun Apr  7 20:49:09 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Sun, 7 Apr 2013 17:49:09 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <C72DED01-1FB6-465E-BC28-21FEE82A1AB2@nasa.gov>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<9DA533E3-2947-4936-9618-2A2C882F7390@gmail.com>
	<C760638F-A10B-4E6C-9733-A78D3311F93C@caltech.edu>
	<C72DED01-1FB6-465E-BC28-21FEE82A1AB2@nasa.gov>
Message-ID: <348ACCFF-4EC8-46C7-8E2F-A8DD1FAC8CF7@caltech.edu>

On Apr 7, 2013, at 5:33 PM, Jeremy Perkins <jeremy.s.perkins at nasa.gov> wrote:

> Hi Leo,
> 
> You can set up pip to install packages to a user-defined location that you add to your python-path.  This could even be in your home directory (like ~/python or ~/.python).  This way you don't have to have root access or install them globally.  That's what I usually do when I'm working on a system that's locked down.

Yes, I know, but I am contemplating making astropy a dependency of LALSuite (https://www.lsc-group.phys.uwm.edu/daswg/projects/lalsuite.html), the software package that comprises the flagship LIGO data analysis pipelines, by introducing some code that I have developed with astropy. Although pip would be fine for development, LALSuite itself is released, packaged, and installed on our cluster nodes for production analyses.

> On Apr 7, 2013, at 8:12 PM, Leo Singer <lsinger at caltech.edu> wrote:
> 
>> John,
>> 
>> Thank you; pip would work except that we need packages that can be installed with apt or yum. Our lab insists on it; the policy must be due to how they manage our computing clusters.
>> 
>> Leo
> 



From brandon at rhodesmill.org  Sun Apr  7 23:22:06 2013
From: brandon at rhodesmill.org (Brandon Rhodes)
Date: Sun, 07 Apr 2013 23:22:06 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu> (Leo Singer's
	message of "Sun, 7 Apr 2013 17:18:37 -0700")
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu>
Message-ID: <871ualemg1.fsf@asaph.rhodesmill.org>

Leo Singer <lsinger at caltech.edu> writes:

> Could you get the time conversion functions that you need from NOVAS
> (http:// aa.usno.navy.mil/software/novas/novas_c/novasc_info.php)?
> Although you would want to contact its maintainers to check, I think
> that NOVAS is not just free, it's actually in the public domain.

You are correct about NOVAS and its status: I was myself able to package
and make NOVAS available on the Python Package Index (as the "novas"
distribution) because it is entirely free of either copyright or
license.

-- 
Brandon Rhodes      brandon at rhodesmill.org      http://rhodesmill.org/brandon


From tim.jenness at gmail.com  Sun Apr  7 23:35:23 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Sun, 7 Apr 2013 20:35:23 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
Message-ID: <CA+G92Rf30SdDS45YfHJ-bsv4FD0SYEU+qTNsZ-GUFmAq5LUTPw@mail.gmail.com>

On Sun, Apr 7, 2013 at 5:22 PM, Tom Aldcroft
<aldcroft at head.cfa.harvard.edu>wrote:

>
> I wonder if it might be worth trying again with SOFA.  Things are a
> little different now since at this point there are real users that are
> unable to use our (and their) software because of their license.  This
> is very frustrating.
>
> I wonder if we could organize a petition in support of modifying the
> SOFA license to something more consistent with typical community
> standards.  I mean the IAU is supposed to be representing and
> benefiting astronomers, no?
>
>
The irony is that the SOFA library was written precisely because the IAU
felt that there should be a solid astrometry library available to the
community. I can't speak for them but I get the impression that they feel
they are trying hard for this to be usable by everyone and don't understand
why everyone who wants to use it is upset about the license. From what I
recall the sticking points are entirely around forking and damaging the IAU
reputation by local patching although I think that much of what they want
can be done by copyright enforcement rather than licensing.

Concrete examples of how people are actively deciding not to use the code
because of the license might help.

-- 
Tim Jenness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130407/dd88a5c6/attachment.html>

From sransom at nrao.edu  Sun Apr  7 23:55:28 2013
From: sransom at nrao.edu (Scott Ransom)
Date: Sun, 07 Apr 2013 23:55:28 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CA+G92Rf30SdDS45YfHJ-bsv4FD0SYEU+qTNsZ-GUFmAq5LUTPw@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
	<CA+G92Rf30SdDS45YfHJ-bsv4FD0SYEU+qTNsZ-GUFmAq5LUTPw@mail.gmail.com>
Message-ID: <51623FB0.5000901@nrao.edu>



On 04/07/2013 11:35 PM, Tim Jenness wrote:
>
>
>
> On Sun, Apr 7, 2013 at 5:22 PM, Tom Aldcroft
> <aldcroft at head.cfa.harvard.edu <mailto:aldcroft at head.cfa.harvard.edu>>
> wrote:
>
>
>     I wonder if it might be worth trying again with SOFA.  Things are a
>     little different now since at this point there are real users that are
>     unable to use our (and their) software because of their license.  This
>     is very frustrating.
>
>     I wonder if we could organize a petition in support of modifying the
>     SOFA license to something more consistent with typical community
>     standards.  I mean the IAU is supposed to be representing and
>     benefiting astronomers, no?
>
>
> The irony is that the SOFA library was written precisely because the IAU
> felt that there should be a solid astrometry library available to the
> community. I can't speak for them but I get the impression that they
> feel they are trying hard for this to be usable by everyone and don't
> understand why everyone who wants to use it is upset about the license.
>  From what I recall the sticking points are entirely around forking and
> damaging the IAU reputation by local patching although I think that much
> of what they want can be done by copyright enforcement rather than
> licensing.
>
> Concrete examples of how people are actively deciding not to use the
> code because of the license might help.

I agree with this.  I know one or two member of the SOFA board fairly 
well and have mentioned this to them.  I think we (along with other 
pressure) can help bring them around -- which is a worthwhile thing to do.

Scott

-- 
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 astropy at liska.ath.cx  Mon Apr  8 03:47:31 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Mon, 08 Apr 2013 09:47:31 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
Message-ID: <ytz1ual8nvw.fsf@news.ole.ath.cx>

Hi all,

2013/4/7 Leo Singer <lsinger at caltech.edu>
> I would like to use Astropy on Debian and Scientific Linux. My
> experiment is pretty strict about using packaged software. Are there
> are there any plans to create .debs or .rpms for Astropy?

A package for astropy is in the NEW queue of Debian [1]. This is still a
prerelease (0.2beta2); the current version is however ready to go [2] once
the Debian ftpmasters accepted the package. Since Debian is currently
focussing on finishing a new release (Wheezy), this takes some time -- the
astropy package is waiting now for 10 weeks.

Best

Ole

[1] http://ftp-master.debian.org/new/python-astropy_0.2~b2-1.html
[2] http://anonscm.debian.org/gitweb/?p=debian-science/packages/python-astropy.git


From astropy at liska.ath.cx  Mon Apr  8 03:55:27 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Mon, 08 Apr 2013 09:55:27 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
Message-ID: <ytzwqsd78y8.fsf@news.ole.ath.cx>

Tom Aldcroft <aldcroft at head.cfa.harvard.edu> writes:
> On Sun, Apr 7, 2013 at 5:50 PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:
>>  * The Fedora legal team reviewed the SOFA license and they considered it
>>    non-free.
>>  * I wrote the SOFA board asking for a license change, they did not answered
>>    my request
>>  * I think the situation in Debian is different

I am afraid that it is not. Althought I could manage to push it into the
Debian repository [1], I would consider this a time bomb. Opinions about
what is considered to be free do not differ much between Debian and
Fedora, so I expect an RC bug mentioning the non-free status of the
library, followed by its removal (and the removal of all dependent
packages as DS9, AST, and soon astropy).

> I wonder if it might be worth trying again with SOFA.  Things are a
> little different now since at this point there are real users that are
> unable to use our (and their) software because of their license.  This
> is very frustrating.

Completely agree.

> I wonder if we could organize a petition in support of modifying the
> SOFA license to something more consistent with typical community
> standards.  I mean the IAU is supposed to be representing and
> benefiting astronomers, no?

I would sign for sure :-)

Best regards

Ole

[1] http://packages.debian.org/source/wheezy/iausofa-c


From astropy at liska.ath.cx  Mon Apr  8 04:19:31 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Mon, 08 Apr 2013 10:19:31 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
	<CA+G92Rf30SdDS45YfHJ-bsv4FD0SYEU+qTNsZ-GUFmAq5LUTPw@mail.gmail.com>
Message-ID: <ytzsj3177u4.fsf@news.ole.ath.cx>

Tim Jenness <tim.jenness at gmail.com> writes:
> The irony is that the SOFA library was written precisely because the IAU felt
> that there should be a solid astrometry library available to the community. I
> can't speak for them but I get the impression that they feel they are trying
> hard for this to be usable by everyone and don't understand why everyone who
> wants to use it is upset about the license. From what I recall the sticking
> points are entirely around forking and damaging the IAU reputation by local
> patching although I think that much of what they want can be done by copyright
> enforcement rather than licensing.

The funny point here is that the license effectively may lead to a
situation which disreputes the IAU: someone can just start a compatible
version of SOFA, starting f.e. from the (GPL version of) SLALIB, and
using the iau_ prefix. Since all functions APIs would then look like
SOFA, a bug could be misinterpreted as one in IAU code.

> Concrete examples of how people are actively deciding not to use the code
> because of the license might help.

I could probably (re-)start some discussion in Debian-legal about the
current license; however this is a bit of Harakiri. Especially since
Wheezy is soming soon, there is a danger that SOFA , AST, and DS9 will
be excluded from this next stable release.

BTW, since the SOFA license is incompatible to the GPL (which is the
license of AST and PAL, which both depend from SOFA, and include its
source code), the Starlink group should also be interested in a license
change of SOFA. Currently, a binary distribution of AST and PAL is
illegal since one cannot provide all its source code under GPL.

The same belongs to DS9; formally their binary distribution is illegal
for the same reason. They however seem not to care.

Best regards

Ole


From embray at stsci.edu  Mon Apr  8 09:18:31 2013
From: embray at stsci.edu (Erik Bray)
Date: Mon, 8 Apr 2013 09:18:31 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KYby5XWToik6p4co+k2s1Tq7wttEkbejefhd5kQdApn0Q@mail.gmail.com>
References: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<1365372650840.085bd476@Nodemailer>
	<CACta-KYby5XWToik6p4co+k2s1Tq7wttEkbejefhd5kQdApn0Q@mail.gmail.com>
Message-ID: <5162C3A7.8020607@stsci.edu>

On 04/07/2013 07:17 PM, Sergio Pascual wrote:
> Disclaimer: I'm a packager in Fedora Linux
>
> John,
>
> pip will download the tarballs of python packages and compile them using the
> available tools in the system. That works well for pure Python
>   packages, but once you start with packages with C dependencies things grow
> fragile. For example, pip won't install the ATLAS libraries if you don't have
> them and you are trying to build numpy. Other packages such as scipy and
> matplotlib are difficult to build properly using pip unless you know what you
> are doing.
>
> So, in my opinion, a precompiled package is much better solution for a casual
> user, someone that wants to write a short script and get a plot quickly.
>
> Unless, of course, you don't have root access.
>
> Regards


For what it's worth, Python has a new officially blessed binary distribution 
format for Python packages called "wheel".  Unlike the old egg format, it is 
based on a standard, and also supports non-pure Python packages well, including 
better indicators for platform support.

For Astropy we've already experimented with building wheels for Numpy and SciPy 
for use in our continuous integration tests (to avoid having to re-build those 
packages repeatedly).  Right now wheel support is only included in the 
development version of pip, but I suspect that once there's a public release 
with that support we'll start getting some official wheel distributions for 
projects such as those.

Now, this does not negate the problem of wanting Astropy in OS package managers, 
but it does help a great deal with installation for average users.

Erik


> 2013/4/8 John Zuhone <jzuhone at gmail.com <mailto:jzuhone at gmail.com>>
>
>     Sergio,
>
>
>     I have no idea what you are talking about when you insinuate that using pip
>     is a roadblock to getting on with "Science."
>
>     You don't have to download or compile any source code at all to use pip.
>     Once installed (from yum or something else), it works just like any other
>     package manager.
>
>     Best,
>
>     John Z
>     ?
>     Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone
>
>
>     On Sun, Apr 7, 2013 at 5:50 PM, Sergio Pascual <sergio.pasra at gmail.com
>     <mailto:sergio.pasra at gmail.com>> wrote:
>
>         Hi,
>
>         the past year we had a discussion about SOFA, an IAU library astropy
>         depends on, see the details here:
>         https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
>
>         In short:
>
>           * The Fedora legal team reviewed the SOFA license and they considered
>         it non-free.
>           * I wrote the SOFA board asking for a license change, they did not
>         answered my request
>           * SOFA and (any program depending on it) *astropy* cannot be included
>         in Fedora or EPEL (Extra Packages for Enterprise Linux) with the current
>         SOFA license.
>           * astropy could be included by *removing* SOFA and the modules
>         depending on it (astropy.time ?)
>           * somebody could package SOFA and astropy in rpmfusion.org
>         <http://rpmfusion.org>, which provides non-free/free-with-legal-problems
>         packages for Fedora and EPEL
>           * or in a different Fedora repository that provides
>           * I think the situation in Debian is different
>
>         Not having precompiled packages available in Fedora/EPEL is very bad for
>         astropy in my opinion. From a small sample of 20
>         Professors-Postdocs-Students in my Astrophysics Department, I can say
>         that only those doing software development use "pip". The vast majority
>         use "yum" in Fedora or "fink/macports" in Mac to bring in the package
>         and continue doing Science.
>
>         Regards, Sergio
>
>
>
>         2013/4/7 Leo Singer <lsinger at caltech.edu <mailto:lsinger at caltech.edu>>
>
>             Hello,
>
>             I would like to use Astropy on Debian and Scientific Linux. My
>             experiment is pretty strict about using packaged software. Are there
>             are there any plans to create .debs or .rpms for Astropy?
>
>             I know how to create packages for both platforms, so I could help,
>             but I don't (yet) know much about how the Debian and Scientific
>             Linux/Red Hat/Fedora communities work, so I would not yet know where
>             or how to submit them.
>
>             Best,
>             Leo Singer
>             Graduate Student @ LIGO-Caltech
>             _______________________________________________
>             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
> http://mail.scipy.org/mailman/listinfo/astropy
>



From thomas.robitaille at gmail.com  Tue Apr  9 08:20:39 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 9 Apr 2013 14:20:39 +0200
Subject: [AstroPy] Astropy and the Google Summer of Code 2013
Message-ID: <CAGMHX_1ATfMvxjN1c+WGXCM1aSce3FqDx792Ocus1dZyzfAx5g@mail.gmail.com>

Dear colleagues,

I am very happy to announce that Astropy will be taking part in the
Google Summer of Code 2013 as part of the Python Software Foundation
organization!

The Google Summer of Code funds students *worldwide* to spend most of
the summer contributing to an approved open-source project, and will
be paid a stipend of USD 5,000 for their work. This is a great
opportunity to get involved with an active open source project, gain
experience, have fun, *and* get financially rewarded for it!

For those of you who are not students, please forward this to people
at your institute and in particular students who you think would be
interested in participating!

I would like to encourage any students who would be interested in
applying to work on Astropy to have a look at the following page for
more information:

https://github.com/astropy/astropy/wiki/Google-Summer-of-Code-2013---Project-Ideas

and join the astropy-dev mailing list to express your interest. The
deadline for student applications to Google is May 3rd, but you should
get in touch with us as soon as possible, as one of the requirements
to participate is to have already submitted a patch to the project.

Please let me know if you have any questions about the program!

Best regards,
Thomas Robitaille
on behalf of the Astropy project


From laidler at stsci.edu  Tue Apr  9 11:02:24 2013
From: laidler at stsci.edu (Victoria G. Laidler)
Date: Tue, 9 Apr 2013 11:02:24 -0400
Subject: [AstroPy] Fwd: Astrostatistics and Astroinformatics Portal
In-Reply-To: <2086703740.6541027.1365120324176.JavaMail.root@psu.edu>
References: <2086703740.6541027.1365120324176.JavaMail.root@psu.edu>
Message-ID: <51642D80.7090703@stsci.edu>

Thought this might be of interest to folks on this list.
Apologies for any inadvertent duplications.

-------- Original Message --------
Subject: 	Astrostatistics and Astroinformatics Portal
Date: 	Thu, 4 Apr 2013 20:05:24 -0400
From: 	Eric D. Feigelson <e5f at psu.edu>
To: 	Eric Feigelson <edf at astro.psu.edu>



This email is an invitation for you to join the Web site 
Astrostatistics and Astroinformatics Portal 
<http://asaip.psu.edu/> (ASAIP, http://asaip.psu.edu 
<http://asaip.psu.edu/>). Astronomers are facing growing 
challenges of analyzing `Big Data' projects like multi-epoch 
wide-field surveys, and of linking complex astronomical 
datasets to astrophysical theory.  Methodology extending the 
narrow suite of familiar methods are increasingly needed for 
understanding astronomical data.  Our community needs to 
improve education in modern statistical and computational 
capabilities, to guide used to software implementing these 
methods, and to foster collaboration between 
astrophysicists, statisticians and information scientists.


ASAIP provides a searchable collection of papers on advanced 
methodology used in astronomy, short articles, discussion 
forums, list of meetings and jobs, links to blogs, on-line 
courses, datasets, and various related Web resources. 
  Members of ASAIP can contribute material and participate 
in discussions.  To join ASAIP, please send a brief email to 
the editors, Eric Feigelson <mailto:%20edf at astro.psu.edu>  
and Joseph Hilbe <mailto:%20hilbe at asu.edu>.


ASAIP is also used by four new organizations devoted to 
promoting advanced statistical and computational methodology 
in astronomy:

  * International Astrostatistics Association, affiliated
    with the International Statistical Institute.  The IAA
    welcomes membership by all students and researchers
    interested in this cross-disciplinary field; contact
    Joseph Hilbe <mailto:%20hilbe at asu.edu> for membership.

  * International Astronomical Union's Working Group in
    Astrostatistics and Astroinformatics.  Members of the
    IAU can join the WG by contacting Eric Feigelson
    <mailto:%20edf at astro.psu.edu>.

  * American Astronomical Society's Working Group in
    Astroinformatics and Astrostatsitics.  Members of the
    AAS can join this WG by contacting Zeljko Ivezic
    <mailto:%20ivezic at astro.washington.edu>.
  * Large Synoptic Survey Telescope's Informatics and
    Statistics Science Collaboration.


Overall, we encourage you to peruse ASAIP 
<http://asaip.psu.edu>, join one of the organizations, and 
participate in community discussions relating to statistics 
and computation.





From erik.tollerud at gmail.com  Tue Apr  9 18:11:34 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Tue, 9 Apr 2013 18:11:34 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
Message-ID: <CAARXUwVuq67CQCr4J9fVMgckRdkTfFpTF6fJeu5_HHpaGBeZdg@mail.gmail.com>

I like the petition idea, and the fact that, as Tom A says, we have a
definite example of people who want to use it but can't... We (the
coordination committee) are still looking into getting something
concrete from SOFA, but thus far it hasn't been too promising.
Hopefully we'll have more on this soon (~few weeks).

 We absolutely want future releases to be fully
Debian/Fedora-compatible, though.  So if SOFA refuses to budge we'll
probably have to switch to our own implementations of whatever SOFA
functions we are currently using.  It wouldn't be the end of the world
or ruin the project, but it would be quite irritating and wasteful of
time (especially for `astropy.time`, given all the work you put into
the SOFA bindings, Tom).

On Sun, Apr 7, 2013 at 8:22 PM, Tom Aldcroft
<aldcroft at head.cfa.harvard.edu> wrote:
> On Sun, Apr 7, 2013 at 5:50 PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:
>> Hi,
>>
>> the past year we had a discussion about SOFA, an IAU library astropy depends
>> on, see the details here:
>> https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
>>
>> In short:
>>
>>  * The Fedora legal team reviewed the SOFA license and they considered it
>> non-free.
>>  * I wrote the SOFA board asking for a license change, they did not answered
>> my request
>>  * SOFA and (any program depending on it) *astropy* cannot be included in
>> Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA
>> license.
>>  * astropy could be included by *removing* SOFA and the modules depending on
>> it (astropy.time ?)
>>  * somebody could package SOFA and astropy in rpmfusion.org, which provides
>> non-free/free-with-legal-problems packages for Fedora and EPEL
>>  * or in a different Fedora repository that provides
>>  * I think the situation in Debian is different
>
> Sergio,
>
> I wonder if it might be worth trying again with SOFA.  Things are a
> little different now since at this point there are real users that are
> unable to use our (and their) software because of their license.  This
> is very frustrating.
>
> I wonder if we could organize a petition in support of modifying the
> SOFA license to something more consistent with typical community
> standards.  I mean the IAU is supposed to be representing and
> benefiting astronomers, no?
>
> Thanks,
> Tom
>
>>
>> Not having precompiled packages available in Fedora/EPEL is very bad for
>> astropy in my opinion. From a small sample of 20
>> Professors-Postdocs-Students in my Astrophysics Department, I can say that
>> only those doing software development use "pip". The vast majority use "yum"
>> in Fedora or "fink/macports" in Mac to bring in the package and continue
>> doing Science.
>>
>> Regards, Sergio
>>
>>
>>
>> 2013/4/7 Leo Singer <lsinger at caltech.edu>
>>>
>>> Hello,
>>>
>>> I would like to use Astropy on Debian and Scientific Linux. My experiment
>>> is pretty strict about using packaged software. Are there are there any
>>> plans to create .debs or .rpms for Astropy?
>>>
>>> I know how to create packages for both platforms, so I could help, but I
>>> don't (yet) know much about how the Debian and Scientific Linux/Red
>>> Hat/Fedora communities work, so I would not yet know where or how to submit
>>> them.
>>>
>>> Best,
>>> Leo Singer
>>> Graduate Student @ LIGO-Caltech
>>> _______________________________________________
>>> 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



-- 
Erik


From arrudy at ucsc.edu  Tue Apr  9 19:14:45 2013
From: arrudy at ucsc.edu (Alexander Rudy)
Date: Tue, 9 Apr 2013 16:14:45 -0700
Subject: [AstroPy] LaTeX packages for Units
Message-ID: <30FBC87A-912C-4C0D-8463-B5E0D597165E@ucsc.edu>

Hey AstroPy,

What packages (feel free to point me to the right page in the docs if I missed this) should I be using to get all of the units commands to show up correctly when I use astropy.units?

Specifically, when I use astropy.units.arcsec, I get $\second$. The only package I get when I google that command is "mathabx"[^1], which doesn't seem to be in TeXLive? 

I'd be happy to throw together some basic documentation for the project on LaTeX symbols if it doesn't already exist (I don't see it in my github clone?)

~ Alex

[1]: http://milde.users.sourceforge.net/LUCR/Math/mathpackages/mathabx-symbols.pdf

From mdroe at stsci.edu  Wed Apr 10 08:54:58 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 10 Apr 2013 08:54:58 -0400
Subject: [AstroPy] LaTeX packages for Units
In-Reply-To: <30FBC87A-912C-4C0D-8463-B5E0D597165E@ucsc.edu>
References: <30FBC87A-912C-4C0D-8463-B5E0D597165E@ucsc.edu>
Message-ID: <51656122.3060200@stsci.edu>

The use of `\second` was ultimately considered a bug (as it doesn't 
exist without additional non standard packages).  It was fixed in 
https://github.com/astropy/astropy/pull/892 which should be in the 
latest 0.2.1 release.  We intend to keep the symbol set to the standard 
ones -- not only does this make the LaTeX installation easier, but it 
keeps it compatible with mathjax used in the IPython notebook.  As part 
of that bugfix, we are now testing the generated LaTeX symbols as part 
of the doc build (which run in an environment without extra math 
packages), so we should catch this kind of thing sooner in the future.

Mike

On 04/09/2013 07:14 PM, Alexander Rudy wrote:
> Hey AstroPy,
>
> What packages (feel free to point me to the right page in the docs if I missed this) should I be using to get all of the units commands to show up correctly when I use astropy.units?
>
> Specifically, when I use astropy.units.arcsec, I get $\second$. The only package I get when I google that command is "mathabx"[^1], which doesn't seem to be in TeXLive?
>
> I'd be happy to throw together some basic documentation for the project on LaTeX symbols if it doesn't already exist (I don't see it in my github clone?)
>
> ~ Alex
>
> [1]: http://milde.users.sourceforge.net/LUCR/Math/mathpackages/mathabx-symbols.pdf
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From sienkiew at stsci.edu  Wed Apr 10 10:52:18 2013
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Wed, 10 Apr 2013 10:52:18 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <C760638F-A10B-4E6C-9733-A78D3311F93C@caltech.edu>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<9DA533E3-2947-4936-9618-2A2C882F7390@gmail.com>
	<C760638F-A10B-4E6C-9733-A78D3311F93C@caltech.edu>
Message-ID: <51657CA2.2020703@stsci.edu>

On 04/07/13 20:12, Leo Singer wrote:
> On Apr 7, 2013, at 1:37 PM, John ZuHone <jzuhone at gmail.com <mailto:jzuhone at gmail.com>> wrote:
>
>> I'd try pip: https://pypi.python.org/pypi/pip
>>
>>
>
> John,
>
> Thank you; pip would work except that we need packages that can be installed with apt or yum. Our lab insists on it; the policy must be due to how they manage our computing clusters.
>

"using apt or yum" does not necessarily require that your package come from the linux distribution.  You can run your own package archive locally that provides packages that are not in the original distribution.  That means that if you want non-free software and you have the right to use that software at your organization, you can make a .deb or .rpm, then put it on your local package archive.  You do *not* distribute it (or allow others to access your local package archive), but your IT staff can still use apt/yum/whatever to maintain a consistent OS configuration across the lab.

Mark S.

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

From derek at astro.physik.uni-goettingen.de  Fri Apr 12 11:47:05 2013
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Fri, 12 Apr 2013 17:47:05 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
Message-ID: <F9C4B0FB-6C2D-4FB7-B442-7C0BAE1E5804@astro.physik.uni-goettingen.de>

Hi,

On 07.04.2013, at 11:50PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:

> Not having precompiled packages available in Fedora/EPEL is very bad for astropy in my opinion. From a small sample of 20 Professors-Postdocs-Students in my Astrophysics Department, I can say that only those doing software development use "pip". The vast majority use "yum" in Fedora or "fink/macports" in Mac to bring in the package and continue doing Science.
> 
as a note on that, I have just created a fink package for astropy 0.2.1, and while I have
not looked at the SOFA license in detail, I could probably upload it on the package tracker
so people could at least download and build their own .debs with it.
It's a rather basic port so far simply using the included wcslib, sofa and expat; from a packaging
point of view it would probably be preferable to put those int o separate packages (and deal
with the licenses separately?)

I am also having trouble creating a .deb that would pass validation by the packing system,
since setup.py install copies byte-compiled .pyc files from the build dir into the installation dir,
and such files (which point to the wrong path after installation) are not accepted in validated
.deb packages. I have not been able to overcome this even trying to rip apart the install steps
in whatever way I found (and I am not an expert with setuptools), so if anyone has an idea how
to tell setuptools/distribute not to copy the .pyc's in the first place (no other package like numpy
or matplotblib does this apparently), I'd be very grateful.

Cheers,
						Derek



From jps at astro.columbia.edu  Fri Apr 12 12:15:32 2013
From: jps at astro.columbia.edu (Joshua Schroeder)
Date: Fri, 12 Apr 2013 12:15:32 -0400
Subject: [AstroPy] Instantiating empty tables
Message-ID: <127CFD92-1AB3-4202-9DEC-F3613C7E8B50@astro.columbia.edu>

I learned yesterday at the CfA code coffee about astropy.table. For my work, I want to instantiate a table that I then populate with data taken from the headers of many different fits observations. The problem is that it looks like I cannot add rows to an empty table. E.g., while this will work:

	>> usefulstuff = Table([['a'],['b'],['c'],['d'],[123.1],['as'],['R'],[213.2],[2.24],['12.25151'],['33.2511']],
						names=('PATH','FILE','TELESCOPE','INSTRUMENT', 'JD', 'OBJECT', 'FILTER', 
								'EXPTIME', 'AIRMASS', 'RA', 'DEC'), 
						dtypes=('a64','a25','a25','a25','f8','a25','a2', 'f8','f8','a25','a25'), 
						masked=True)
	>> usefulstuff.add_row(['a','b','c','d',123.1,'as','R',213.2,2.24,'12.25151','33.2511'])
	>> print usefulstuff
	PATH FILE TELESCOPE INSTRUMENT   JD  OBJECT FILTER EXPTIME AIRMASS    RA      DEC  
	---- ---- --------- ---------- ----- ------ ------ ------- ------- -------- -------
	   a    b         c          d 123.1     as      R   213.2    2.24 12.25151 33.2511
	   a    b         c          d 123.1     as      R   213.2    2.24 12.25151 33.2511


What does not work is:

	>> usefulstuff = Table(names=('PATH','FILE','TELESCOPE','INSTRUMENT',
                                                               'JD', 'OBJECT', 'FILTER', 'EXPTIME',
                                                               'AIRMASS', 'RA', 'DEC'),
                                               dtypes=('a64','a25','a25','a25','f8','a25','a2',
                                                               'f8','f8','a25','a25'), masked=True)

	>> usefulstuff.add_row(['a','b','c','d',123.1,'as','R',213.2,2.24,'12.25151','33.2511'])
	ERROR: TypeError: Empty data-type [numpy.core.fromnumeric]
	---------------------------------------------------------------------------
	TypeError                                 Traceback (most recent call last)
	/home/data/<ipython-input-227-985123887cc4> in <module>()
	----> 1 usefulstuff.add_row(['a','b','c','d',123.1,'as','R',213.2,2.24,'12.25151','33.2511'])

	/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/site-packages/astropy/table/table.pyc in add_row(self, vals, mask)
	   1584 
	   1585         if self.masked:
	-> 1586             self._data = ma.resize(self._data, (newlen,))
	   1587         else:
	   1588             self._data.resize((newlen,), refcheck=False)

	/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/site-packages/numpy/ma/core.pyc in resize(x, new_shape)
	   6460     m = getmask(x)
	   6461     if m is not nomask:
	-> 6462         m = np.resize(m, new_shape)
	   6463     result = np.resize(x, new_shape).view(get_masked_subclass(x))
	   6464     if result.ndim:

	/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/site-packages/numpy/core/fromnumeric.pyc in resize(a, new_shape)
	    850     a = ravel(a)
	    851     Na = len(a)
	--> 852     if not Na: return mu.zeros(new_shape, a.dtype.char)
	    853     total_size = um.multiply.reduce(new_shape)
	    854     n_copies = int(total_size / Na)

	TypeError: Empty data-type

Do I really need to instantiate a table with a dummy row that I then delete after populating the table or, for example, do I need to read the data into arrays and only make the table after looping over files?

From lsinger at caltech.edu  Fri Apr 12 14:06:51 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Fri, 12 Apr 2013 11:06:51 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <mailman.0.1365786002.18478.astropy@scipy.org>
References: <mailman.0.1365786002.18478.astropy@scipy.org>
Message-ID: <2A775338-E0DA-47DA-A10E-DA173DC66B52@caltech.edu>

On Apr 12, 2013, at 10:00 AM, astropy-request at scipy.org wrote:

> From: Derek Homeier <derek at astro.physik.uni-goettingen.de>
> Subject: Re: [AstroPy] astropy in Debian, Scientific Linux?
> Date: April 12, 2013 8:47:05 AM PDT
> To: "astropy at scipy.org list" <astropy at scipy.org>
> 
> 
> Hi,
> 
> On 07.04.2013, at 11:50PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:
> 
>> Not having precompiled packages available in Fedora/EPEL is very bad for astropy in my opinion. From a small sample of 20 Professors-Postdocs-Students in my Astrophysics Department, I can say that only those doing software development use "pip". The vast majority use "yum" in Fedora or "fink/macports" in Mac to bring in the package and continue doing Science.
>> 
> as a note on that, I have just created a fink package for astropy 0.2.1, and while I have
> not looked at the SOFA license in detail, I could probably upload it on the package tracker
> so people could at least download and build their own .debs with it.
> It's a rather basic port so far simply using the included wcslib, sofa and expat; from a packaging
> point of view it would probably be preferable to put those int o separate packages (and deal
> with the licenses separately?)
> 
> I am also having trouble creating a .deb that would pass validation by the packing system,
> since setup.py install copies byte-compiled .pyc files from the build dir into the installation dir,
> and such files (which point to the wrong path after installation) are not accepted in validated
> .deb packages. I have not been able to overcome this even trying to rip apart the install steps
> in whatever way I found (and I am not an expert with setuptools), so if anyone has an idea how
> to tell setuptools/distribute not to copy the .pyc's in the first place (no other package like numpy
> or matplotblib does this apparently), I'd be very grateful.

Derek,

Are you saying that fink is somehow creating .debs? Where are you developing your Debian packaging? I could take a look at it.

Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130412/d71981d6/attachment.html>

From derek at astro.physik.uni-goettingen.de  Fri Apr 12 15:56:29 2013
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Fri, 12 Apr 2013 21:56:29 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <2A775338-E0DA-47DA-A10E-DA173DC66B52@caltech.edu>
References: <mailman.0.1365786002.18478.astropy@scipy.org>
	<2A775338-E0DA-47DA-A10E-DA173DC66B52@caltech.edu>
Message-ID: <ABCB0284-9AC7-4A61-9991-ABCAA1C3BC16@astro.physik.uni-goettingen.de>

Hi Leo,

On 12.04.2013, at 8:06PM, Leo Singer <lsinger at caltech.edu> wrote:

> Are you saying that fink is somehow creating .debs? Where are you developing your Debian packaging? I could take a look at it.
> 
yes, fink is using .debs and dpkg and apt-get to manage them, but with everything sitting below the
Fink packaging manager that takes care of downloading and building packages from source, so
it's rather transparent to the normal user. I don't know how the .info files to build the package relate
to the way they are built in Debian, but the main build and install steps, I hope, should be well enough
understandable from the package description, attached below.
I've made some crude attempts to fix the .pyc problem, but no solution so far works satisfactorily.

Thanks for any advice,

						Derek

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: astropy-py.info
Type: application/octet-stream
Size: 3893 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20130412/c4c1fcb8/attachment.obj>
-------------- next part --------------
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: astropy-py.patch
Type: application/octet-stream
Size: 578 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20130412/c4c1fcb8/attachment-0001.obj>

From sergio.pasra at gmail.com  Sun Apr 14 18:49:39 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Mon, 15 Apr 2013 00:49:39 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu>
Message-ID: <CACta-Kard1W3HKg0rd+_G2HrdNarMos8dv8vo8s59kLkni2Axw@mail.gmail.com>

It would be really interesting to have NOVAS as a precompiled library if,
as you say, it's in the public domain. I will check it, thanks


2013/4/8 Leo Singer <lsinger at caltech.edu>

> On Apr 7, 2013, at 2:50 PM, Sergio Pascual <sergio.pasra at gmail.com> wrote:
>
> the past year we had a discussion about SOFA, an IAU library astropy
> depends on, see the details here:
> https://groups.google.com/d/topic/astropy-dev/QVpMZFlsQUo/discussion
>
> In short:
>
>  * The Fedora legal team reviewed the SOFA license and they considered it
> non-free.
>  * I wrote the SOFA board asking for a license change, they did not
> answered my request
>  * SOFA and (any program depending on it) *astropy* cannot be included in
> Fedora or EPEL (Extra Packages for Enterprise Linux) with the current SOFA
> license.
>  * astropy could be included by *removing* SOFA and the modules depending
> on it (astropy.time ?)
>  * somebody could package SOFA and astropy in rpmfusion.org, which
> provides non-free/free-with-legal-problems packages for Fedora and EPEL
>  * or in a different Fedora repository that provides
>  * I think the situation in Debian is different
>
> Not having precompiled packages available in Fedora/EPEL is very bad for
> astropy in my opinion. From a small sample of 20
> Professors-Postdocs-Students in my Astrophysics Department, I can say that
> only those doing software development use "pip". The vast majority use
> "yum" in Fedora or "fink/macports" in Mac to bring in the package and
> continue doing Science.
>
>
>  Wow, the SOFA license **is** pretty strange. What a shame.
>
> Could you get the time conversion functions that you need from NOVAS (
> http://aa.usno.navy.mil/software/novas/novas_c/novasc_info.php)? Although
> you would want to contact its maintainers to check, I think that NOVAS is
> not just free, it's actually in the public domain.
>
> Leo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130415/49b4614b/attachment.html>

From brandon at rhodesmill.org  Sun Apr 14 18:52:38 2013
From: brandon at rhodesmill.org (Brandon Rhodes)
Date: Sun, 14 Apr 2013 18:52:38 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-Kard1W3HKg0rd+_G2HrdNarMos8dv8vo8s59kLkni2Axw@mail.gmail.com>
	(Sergio Pascual's message of "Mon, 15 Apr 2013 00:49:39 +0200")
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu>
	<CACta-Kard1W3HKg0rd+_G2HrdNarMos8dv8vo8s59kLkni2Axw@mail.gmail.com>
Message-ID: <87mwt07mix.fsf@asaph.rhodesmill.org>

Sergio Pascual <sergio.pasra at gmail.com> writes:

> It would be really interesting to have NOVAS as a precompiled library
> if, as you say, it's in the public domain. I will check it, thanks

Note that I have already packaged it up on the Python Package Index so
that you can have its Python bindings up and running with the command:

pip install novas

-- 
Brandon Rhodes      brandon at rhodesmill.org      http://rhodesmill.org/brandon


From sergio.pasra at gmail.com  Sun Apr 14 18:55:57 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Mon, 15 Apr 2013 00:55:57 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <87mwt07mix.fsf@asaph.rhodesmill.org>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<1D3087D2-A59E-4F8B-A5D7-3987B2B20CEE@caltech.edu>
	<CACta-Kard1W3HKg0rd+_G2HrdNarMos8dv8vo8s59kLkni2Axw@mail.gmail.com>
	<87mwt07mix.fsf@asaph.rhodesmill.org>
Message-ID: <CACta-KZWLcEWDBMOg1gUZxCDuZx7souJLPM5G2eqfBxWMaOhcw@mail.gmail.com>

I was checking it in Pypi just now :)


2013/4/15 Brandon Rhodes <brandon at rhodesmill.org>

> Sergio Pascual <sergio.pasra at gmail.com> writes:
>
> > It would be really interesting to have NOVAS as a precompiled library
> > if, as you say, it's in the public domain. I will check it, thanks
>
> Note that I have already packaged it up on the Python Package Index so
> that you can have its Python bindings up and running with the command:
>
> pip install novas
>
> --
> Brandon Rhodes      brandon at rhodesmill.org
> http://rhodesmill.org/brandon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130415/5966375f/attachment.html>

From sergio.pasra at gmail.com  Sun Apr 14 19:04:47 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Mon, 15 Apr 2013 01:04:47 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
Message-ID: <CACta-KZwD5BqW=UhGq0xbQh_ZxTe0jKpxFeiy1ESEFn76oTD_Q@mail.gmail.com>

In my opinion the best idea is to create a petition. It seems my mail
wasn't very effective

2013/4/8 Tom Aldcroft <aldcroft at head.cfa.harvard.edu>

> Sergio,
>
> I wonder if it might be worth trying again with SOFA.  Things are a
> little different now since at this point there are real users that are
> unable to use our (and their) software because of their license.  This
> is very frustrating.
>
> I wonder if we could organize a petition in support of modifying the
> SOFA license to something more consistent with typical community
> standards.  I mean the IAU is supposed to be representing and
> benefiting astronomers, no?
>
> Thanks,
> Tom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130415/cd61346a/attachment.html>

From jturner at gemini.edu  Mon Apr 15 14:00:57 2013
From: jturner at gemini.edu (James Turner)
Date: Mon, 15 Apr 2013 14:00:57 -0400
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KZwD5BqW=UhGq0xbQh_ZxTe0jKpxFeiy1ESEFn76oTD_Q@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
	<CACta-KZwD5BqW=UhGq0xbQh_ZxTe0jKpxFeiy1ESEFn76oTD_Q@mail.gmail.com>
Message-ID: <516C4059.7090506@gemini.edu>

> In my opinion the best idea is to create a petition. It seems my mail wasn't
> very effective

+1. Individuals whining obviously aren't going to get anywhere.
It needs to be made clear to the IAU that it isn't serving the
best interests of its community and that the future of progress
in data processing is in open source.

The other thing would be to persuade a different part of IAU to
take up the cause, eg. SOFA comes under division A (fundamental
astronomy) whereas data science is division B. This discussion
should be driven by top-level considerations as to what
astronomers need, not theoretical logistical concerns. It won't
matter what people think of SOFA if no-one uses it -- and as
someone (Sergio?) mentioned, it's worth pointing out the anomaly
that anyone can write software that appears to be the original
SOFA as long as it *isn't* (and therefore bound by their
licence), rendering the naming restrictions fairly pointless.

Anyone here a member? I spot only a handful of people I know
under their division listings.

Cheers,

James.


> 2013/4/8 Tom Aldcroft <aldcroft at head.cfa.harvard.edu
> <mailto:aldcroft at head.cfa.harvard.edu>>
>
>     Sergio,
>
>     I wonder if it might be worth trying again with SOFA.  Things are a
>     little different now since at this point there are real users that are
>     unable to use our (and their) software because of their license.  This
>     is very frustrating.
>
>     I wonder if we could organize a petition in support of modifying the
>     SOFA license to something more consistent with typical community
>     standards.  I mean the IAU is supposed to be representing and
>     benefiting astronomers, no?
>
>     Thanks,
>     Tom
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From sergio.pasra at gmail.com  Mon Apr 15 18:11:04 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Tue, 16 Apr 2013 00:11:04 +0200
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <516C4059.7090506@gemini.edu>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
	<CACta-KZwD5BqW=UhGq0xbQh_ZxTe0jKpxFeiy1ESEFn76oTD_Q@mail.gmail.com>
	<516C4059.7090506@gemini.edu>
Message-ID: <CACta-KZx0oVzkpEzoET+fg=yMYgNUQLeKXUAHpOkv9LSkBaA0Q@mail.gmail.com>

Incidentally, somewhere in my hard drive I have a version of SOFA with
autotools + libtool + pkgconfig support that I would really like to
contribute if SOFA changes its license. Currently the build system is just
a Makefile, without shared library support.

I was Ole who mentioned the anomaly "that anyone can write software that
appears to be the original
SOFA as long as it *isn't* "

Regards

2013/4/15 James Turner <jturner at gemini.edu>

> > In my opinion the best idea is to create a petition. It seems my mail
> wasn't
> > very effective
>
> +1. Individuals whining obviously aren't going to get anywhere.
> It needs to be made clear to the IAU that it isn't serving the
> best interests of its community and that the future of progress
> in data processing is in open source.
>
> The other thing would be to persuade a different part of IAU to
> take up the cause, eg. SOFA comes under division A (fundamental
> astronomy) whereas data science is division B. This discussion
> should be driven by top-level considerations as to what
> astronomers need, not theoretical logistical concerns. It won't
> matter what people think of SOFA if no-one uses it -- and as
> someone (Sergio?) mentioned, it's worth pointing out the anomaly
> that anyone can write software that appears to be the original
> SOFA as long as it *isn't* (and therefore bound by their
> licence), rendering the naming restrictions fairly pointless.
>
> Anyone here a member? I spot only a handful of people I know
> under their division listings.
>
> Cheers,
>
> James.
>
>
> > 2013/4/8 Tom Aldcroft <aldcroft at head.cfa.harvard.edu
> > <mailto:aldcroft at head.cfa.harvard.edu>>
> >
> >     Sergio,
> >
> >     I wonder if it might be worth trying again with SOFA.  Things are a
> >     little different now since at this point there are real users that
> are
> >     unable to use our (and their) software because of their license.
>  This
> >     is very frustrating.
> >
> >     I wonder if we could organize a petition in support of modifying the
> >     SOFA license to something more consistent with typical community
> >     standards.  I mean the IAU is supposed to be representing and
> >     benefiting astronomers, no?
> >
> >     Thanks,
> >     Tom
> >
> >
> >
> > _______________________________________________
> > 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/20130416/393f8af9/attachment.html>

From tim.jenness at gmail.com  Mon Apr 15 18:16:07 2013
From: tim.jenness at gmail.com (Tim Jenness)
Date: Mon, 15 Apr 2013 15:16:07 -0700
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <CACta-KZx0oVzkpEzoET+fg=yMYgNUQLeKXUAHpOkv9LSkBaA0Q@mail.gmail.com>
References: <798E1333-1A14-4064-B807-D133BC292D27@caltech.edu>
	<CACta-KaTv1oeWrGcaz9PGAcagMxMS9qbN3dMPZ7aB_peU_700g@mail.gmail.com>
	<CAGsQ-NuiX4j3SL54Bz1ONRBqRTqe1WtSneKRhpBB4BuZQb8axw@mail.gmail.com>
	<CACta-KZwD5BqW=UhGq0xbQh_ZxTe0jKpxFeiy1ESEFn76oTD_Q@mail.gmail.com>
	<516C4059.7090506@gemini.edu>
	<CACta-KZx0oVzkpEzoET+fg=yMYgNUQLeKXUAHpOkv9LSkBaA0Q@mail.gmail.com>
Message-ID: <CA+G92RcpUVfwEZJFKanUZ_uE1iENsaS6RNwxTs6iV6dUzO2BRg@mail.gmail.com>

See also: https://github.com/Starlink/sofa


On Mon, Apr 15, 2013 at 3:11 PM, Sergio Pascual <sergio.pasra at gmail.com>wrote:

> Incidentally, somewhere in my hard drive I have a version of SOFA with
> autotools + libtool + pkgconfig support that I would really like to
> contribute if SOFA changes its license. Currently the build system is just
> a Makefile, without shared library support.
>
> I was Ole who mentioned the anomaly "that anyone can write software that
> appears to be the original
>
> SOFA as long as it *isn't* "
>
> Regards
>
>
> 2013/4/15 James Turner <jturner at gemini.edu>
>
>> > In my opinion the best idea is to create a petition. It seems my mail
>> wasn't
>> > very effective
>>
>> +1. Individuals whining obviously aren't going to get anywhere.
>> It needs to be made clear to the IAU that it isn't serving the
>> best interests of its community and that the future of progress
>> in data processing is in open source.
>>
>> The other thing would be to persuade a different part of IAU to
>> take up the cause, eg. SOFA comes under division A (fundamental
>> astronomy) whereas data science is division B. This discussion
>> should be driven by top-level considerations as to what
>> astronomers need, not theoretical logistical concerns. It won't
>> matter what people think of SOFA if no-one uses it -- and as
>> someone (Sergio?) mentioned, it's worth pointing out the anomaly
>> that anyone can write software that appears to be the original
>> SOFA as long as it *isn't* (and therefore bound by their
>> licence), rendering the naming restrictions fairly pointless.
>>
>> Anyone here a member? I spot only a handful of people I know
>> under their division listings.
>>
>> Cheers,
>>
>> James.
>>
>>
>> > 2013/4/8 Tom Aldcroft <aldcroft at head.cfa.harvard.edu
>> > <mailto:aldcroft at head.cfa.harvard.edu>>
>> >
>> >     Sergio,
>> >
>> >     I wonder if it might be worth trying again with SOFA.  Things are a
>> >     little different now since at this point there are real users that
>> are
>> >     unable to use our (and their) software because of their license.
>>  This
>> >     is very frustrating.
>> >
>> >     I wonder if we could organize a petition in support of modifying the
>> >     SOFA license to something more consistent with typical community
>> >     standards.  I mean the IAU is supposed to be representing and
>> >     benefiting astronomers, no?
>> >
>> >     Thanks,
>> >     Tom
>> >
>> >
>> >
>> > _______________________________________________
>> > 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/20130415/b63916c7/attachment.html>

From crawford at saao.ac.za  Tue Apr 16 03:34:21 2013
From: crawford at saao.ac.za (Steve Crawford)
Date: Tue, 16 Apr 2013 09:34:21 +0200 (SAST)
Subject: [AstroPy] astropy in Debian, Scientific Linux?
In-Reply-To: <516C4059.7090506@gemini.edu>
Message-ID: <b8843a7b-d8a0-4a2b-bd2e-731fc55808ac@mailcape>


I'm a member of Division B although I'm not sure how much that should/could help.   However, if we put together a petition/statement then I'm happy to try to push it through in that direction.   I also know Jeff Percival (on the SOFA board) very well, and I'll get in touch with him.   I haven't been following this particularly closely and not sure if I understand all the details, but if someone can send me a summary of the changes we would like, I'd be happy to help as I can.   

----- Original Message -----
> From: "James Turner" <jturner at gemini.edu>
> To: astropy at scipy.org
> Sent: Monday, 15 April, 2013 8:00:57 PM
> Subject: Re: [AstroPy] astropy in Debian, Scientific Linux?
> 
> > In my opinion the best idea is to create a petition. It seems my
> > mail wasn't
> > very effective
> 
> +1. Individuals whining obviously aren't going to get anywhere.
> It needs to be made clear to the IAU that it isn't serving the
> best interests of its community and that the future of progress
> in data processing is in open source.
> 
> The other thing would be to persuade a different part of IAU to
> take up the cause, eg. SOFA comes under division A (fundamental
> astronomy) whereas data science is division B. This discussion
> should be driven by top-level considerations as to what
> astronomers need, not theoretical logistical concerns. It won't
> matter what people think of SOFA if no-one uses it -- and as
> someone (Sergio?) mentioned, it's worth pointing out the anomaly
> that anyone can write software that appears to be the original
> SOFA as long as it *isn't* (and therefore bound by their
> licence), rendering the naming restrictions fairly pointless.
> 
> Anyone here a member? I spot only a handful of people I know
> under their division listings.
> 
> Cheers,
> 
> James.
> 
> 
> > 2013/4/8 Tom Aldcroft <aldcroft at head.cfa.harvard.edu
> > <mailto:aldcroft at head.cfa.harvard.edu>>
> >
> >     Sergio,
> >
> >     I wonder if it might be worth trying again with SOFA.  Things
> >     are a
> >     little different now since at this point there are real users
> >     that are
> >     unable to use our (and their) software because of their
> >     license.  This
> >     is very frustrating.
> >
> >     I wonder if we could organize a petition in support of
> >     modifying the
> >     SOFA license to something more consistent with typical
> >     community
> >     standards.  I mean the IAU is supposed to be representing and
> >     benefiting astronomers, no?
> >
> >     Thanks,
> >     Tom
> >
> >
> >
> > _______________________________________________
> > 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 jjk at uvic.ca  Tue Apr 16 17:43:10 2013
From: jjk at uvic.ca (JJ Kavelaars)
Date: Tue, 16 Apr 2013 14:43:10 -0700
Subject: [AstroPy] How to append to a astropy.io.votable
Message-ID: <2F205F1F-69CB-4C2C-A006-822E09C93149@uvic.ca>

Hi,

i've been using atpy for VOTable manipulation and I'm working to switch to astropy.io.votable.

I don't see how 'add_column' to a table object? 

et.

>>> from astropy.io.votable import parse
>>> from astropy.io.votable.tree import Field

>>> t = parse('filename.vot').get_first_table()
>>> t.fields.append(Field(t,name='newColumn',datatype='int'))
>>> print t.array['newColumn']
ERROR: ValueError: field named newColumn not found. [numpy.ma.core]

??? 

I'd like to add a column to t where that column contains a computed value based on one of t's other columns. 


Hints appreciated.

JJ

--




From aldcroft at head.cfa.harvard.edu  Tue Apr 16 18:15:25 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Tue, 16 Apr 2013 18:15:25 -0400
Subject: [AstroPy] How to append to a astropy.io.votable
In-Reply-To: <2F205F1F-69CB-4C2C-A006-822E09C93149@uvic.ca>
References: <2F205F1F-69CB-4C2C-A006-822E09C93149@uvic.ca>
Message-ID: <CAGsQ-NsfR2Zo+_qGFi5Szrad=Xm=1SJr=OwCj3W4uHPTmCag=Q@mail.gmail.com>

Hi JJ,

If you want to add a column you should first convert the VOtable into
an astropy Table object, e.g.:

  >>> from astropy.table import MaskedColumn
  >>> table = t.to_table()  # where t is the VOtable from your example
  >>> new_col = MaskedColumn(data=<computed values>, name='newColumn')
  >>> table.add_column(new_col)

The use of MaskedColumn assumes there might be missing (masked) values
in your <computed values>.  If not you can just use Column.

Note that in the upcoming 0.3 version of astropy (or the current dev
version), you can replace the last two lines with:

  >>> data['newColumn'] = <computed values>

See also:
 http://docs.astropy.org/en/v0.2.1/io/votable/index.html#converting-to-from-an-astropy-table-table

Cheers,
Tom

On Tue, Apr 16, 2013 at 5:43 PM, JJ Kavelaars <jjk at uvic.ca> wrote:
> Hi,
>
> i've been using atpy for VOTable manipulation and I'm working to switch to astropy.io.votable.
>
> I don't see how 'add_column' to a table object?
>
> et.
>
>>>> from astropy.io.votable import parse
>>>> from astropy.io.votable.tree import Field
>
>>>> t = parse('filename.vot').get_first_table()
>>>> t.fields.append(Field(t,name='newColumn',datatype='int'))
>>>> print t.array['newColumn']
> ERROR: ValueError: field named newColumn not found. [numpy.ma.core]
>
> ???
>
> I'd like to add a column to t where that column contains a computed value based on one of t's other columns.
>
>
> Hints appreciated.
>
> JJ
>
> --
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From demitri.muna at gmail.com  Tue Apr 16 18:29:43 2013
From: demitri.muna at gmail.com (Demitri Muna)
Date: Tue, 16 Apr 2013 18:29:43 -0400
Subject: [AstroPy] SciCoder Workshop 2013 Announcement, NYC
Message-ID: <00A1A570-54B1-4F92-8A7E-25541250102D@gmail.com>

Hello,

I would like to announce the fourth SciCoder workshop being held in NYC. This workshop may be of interest to young researchers (graduate students and postdocs), and it is designed to introduce modern programming practices, languages, and tools as specifically applicable to scientific research. The workshop includes hands-on coding and data analysis. A limited number of seats available to ensure a personalized experience. This program has been very successful over the past three years and we've received a lot of positive feedback; we look forward to seeing this year's participants!

This year the workshop is being held from 8-12 July in New York City. Applications are now being accepted through 17 May 2013. Further details about the workshop can be found here:

http://scicoder.org/workshop

A poster will available for downloading from the web site tomorrow; I would appreciate it if you could post it in your departments.

Cheers,
Demitri

_________________________________________
Demitri Muna

Department of Astronomy
Ohio State University

http://scicoder.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130416/bdf392e8/attachment.html>

From jjk at uvic.ca  Tue Apr 16 18:57:31 2013
From: jjk at uvic.ca (JJ Kavelaars)
Date: Tue, 16 Apr 2013 15:57:31 -0700
Subject: [AstroPy] How to append to a astropy.io.votable
In-Reply-To: <CAGsQ-NsfR2Zo+_qGFi5Szrad=Xm=1SJr=OwCj3W4uHPTmCag=Q@mail.gmail.com>
References: <2F205F1F-69CB-4C2C-A006-822E09C93149@uvic.ca>
	<CAGsQ-NsfR2Zo+_qGFi5Szrad=Xm=1SJr=OwCj3W4uHPTmCag=Q@mail.gmail.com>
Message-ID: <EB6C9F6F-4F49-446B-A387-5D1A5E03CF02@uvic.ca>

Hi Tom,

Thanks for the pointer.  

Also, I see that mapping of 'name' from VOTable to Table has been resolved so, I gather, one doesn't loose content on moving into a Table object.  Great!

JJ


On 2013-04-16, at 3:15 PM, Tom Aldcroft wrote:

> Hi JJ,
> 
> If you want to add a column you should first convert the VOtable into
> an astropy Table object, e.g.:
> 
>>>> from astropy.table import MaskedColumn
>>>> table = t.to_table()  # where t is the VOtable from your example
>>>> new_col = MaskedColumn(data=<computed values>, name='newColumn')
>>>> table.add_column(new_col)
> 
> The use of MaskedColumn assumes there might be missing (masked) values
> in your <computed values>.  If not you can just use Column.
> 
> Note that in the upcoming 0.3 version of astropy (or the current dev
> version), you can replace the last two lines with:
> 
>>>> data['newColumn'] = <computed values>
> 
> See also:
> http://docs.astropy.org/en/v0.2.1/io/votable/index.html#converting-to-from-an-astropy-table-table
> 
> Cheers,
> Tom
> 
> On Tue, Apr 16, 2013 at 5:43 PM, JJ Kavelaars <jjk at uvic.ca> wrote:
>> Hi,
>> 
>> i've been using atpy for VOTable manipulation and I'm working to switch to astropy.io.votable.
>> 
>> I don't see how 'add_column' to a table object?
>> 
>> et.
>> 
>>>>> from astropy.io.votable import parse
>>>>> from astropy.io.votable.tree import Field
>> 
>>>>> t = parse('filename.vot').get_first_table()
>>>>> t.fields.append(Field(t,name='newColumn',datatype='int'))
>>>>> print t.array['newColumn']
>> ERROR: ValueError: field named newColumn not found. [numpy.ma.core]
>> 
>> ???
>> 
>> I'd like to add a column to t where that column contains a computed value based on one of t's other columns.
>> 
>> 
>> Hints appreciated.
>> 
>> JJ
>> 
>> --
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> 



From indiajoe at gmail.com  Thu Apr 18 11:34:01 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Thu, 18 Apr 2013 21:04:01 +0530
Subject: [AstroPy] Linearity correction by polynomial fitting
Message-ID: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>

Hi,

Context:
I have a data cube, which is from an up-the-ramp readout of a detector.
(i.e. data cube with the axis X pixel,Y pixel and Time)
In order to fit a linearity correction function which maps from detector
counts to actual count, I was planning to fit a straight line on the time
axis (for each pixel), upto a threshold and then fit a 2 or 3 degree
polynomial to map the difference between the extrapolated straight line and
the non-linear counts of the pixel above the threshold (till it hits hard
saturation).

Now, the issue: [I want to avoid any python loops.]
Calculating the slope and difference could be easily implemented by numpy
masked array multiplications and other ndarray arithmetic.
But I couldn't find anything for fitting a polynomial for every pixel along
an axis of an ndarray.
Is there a tool to do this? Without implementing a python loop to loop
through each pixel and calculate coefficients?
Worst case scenario, i think i will have to write a C routine to do
polynomial fit and call it from python. But i would really love if a pure
python alternative exists.

Thanks
-cheers
joe





-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130418/6e1fb794/attachment.html>

From jturner at gemini.edu  Thu Apr 18 13:19:33 2013
From: jturner at gemini.edu (James Turner)
Date: Thu, 18 Apr 2013 13:19:33 -0400
Subject: [AstroPy] Linearity correction by polynomial fitting
In-Reply-To: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
References: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
Message-ID: <51702B25.2050701@gemini.edu>

> But I couldn't find anything for fitting a polynomial for every pixel along an
> axis of an ndarray.
> Is there a tool to do this? Without implementing a python loop to loop through
> each pixel and calculate coefficients?

I'm not sure if there is anything yet (could tell you how to do
it in IRAF), as I think fitting has been a bit of a missing area
in Python until some recent work-in-progress. But wouldn't it
help to use Cython? I was also wondering whether a Python loop
will really be that slow if you're doing something relatively
non-trivial like a fit, but it probably will be since the axis
you're fitting will be much shorter than the image size...

Cheers,

James.


> Worst case scenario, i think i will have to write a C routine to do polynomial
> fit and call it from python. But i would really love if a pure python
> alternative exists.
>
> Thanks
> -cheers
> joe
>
>
>
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From indiajoe at gmail.com  Thu Apr 18 15:00:11 2013
From: indiajoe at gmail.com (Joe Philip Ninan)
Date: Fri, 19 Apr 2013 00:30:11 +0530
Subject: [AstroPy] Linearity correction by polynomial fitting
In-Reply-To: <51702B25.2050701@gemini.edu>
References: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
	<51702B25.2050701@gemini.edu>
Message-ID: <CAJ_T+b69AyVtQ_DHgwVw7nztCb6Y+81iVx6H-_yE3cGswK+LpQ@mail.gmail.com>

Hi James,
I think i shall try to keep the code as much pure python as possible.
Installing iraf on the controller machine just for one routine will
probably be an over kill.
Nadia sent me link to pull request of astropy which can do fitting on 2d
array. So i only have to flatten by 3d to a 2d, with time along the column.
( https://github.com/astropy/astropy/pull/493 ).
This isn't merged to astropy yet, but i was told it will be merged soon.
Thanks for the suggestions,
-cheers
joe


On 18 April 2013 22:49, James Turner <jturner at gemini.edu> wrote:

> > But I couldn't find anything for fitting a polynomial for every pixel
> along an
> > axis of an ndarray.
> > Is there a tool to do this? Without implementing a python loop to loop
> through
> > each pixel and calculate coefficients?
>
> I'm not sure if there is anything yet (could tell you how to do
> it in IRAF), as I think fitting has been a bit of a missing area
> in Python until some recent work-in-progress. But wouldn't it
> help to use Cython? I was also wondering whether a Python loop
> will really be that slow if you're doing something relatively
> non-trivial like a fit, but it probably will be since the axis
> you're fitting will be much shorter than the image size...
>
> Cheers,
>
> James.
>
>
> > Worst case scenario, i think i will have to write a C routine to do
> polynomial
> > fit and call it from python. But i would really love if a pure python
> > alternative exists.
> >
> > Thanks
> > -cheers
> > joe
> >
> >
> >
> >
> >
> > --
> > /---------------------------------------------------------------
> > "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
> >
> > ************************************************
> > Joe Philip Ninan http://sites.google.com/site/jpninan/
> > Research Scholar        /________________\
> > DAA,                            | Vadakeparambil |
> > TIFR,                           | Pullad P.O.         |
> > Mumbai-05, India.      | Kerala, India      |
> > Ph: +917738438212   | PIN:689548       |
> > ------------------------------\_______________/--------------
> >
> >
> > _______________________________________________
> > 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
>



-- 
/---------------------------------------------------------------
"GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation

************************************************
Joe Philip Ninan    http://sites.google.com/site/jpninan/
Research Scholar        /________________\
DAA,                            | Vadakeparambil |
TIFR,                           | Pullad P.O.         |
Mumbai-05, India.      | Kerala, India      |
Ph: +917738438212   | PIN:689548       |
------------------------------\_______________/--------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130419/07d63e87/attachment.html>

From jturner at gemini.edu  Thu Apr 18 15:03:39 2013
From: jturner at gemini.edu (James Turner)
Date: Thu, 18 Apr 2013 15:03:39 -0400
Subject: [AstroPy] Linearity correction by polynomial fitting
In-Reply-To: <CAJ_T+b69AyVtQ_DHgwVw7nztCb6Y+81iVx6H-_yE3cGswK+LpQ@mail.gmail.com>
References: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
	<51702B25.2050701@gemini.edu>
	<CAJ_T+b69AyVtQ_DHgwVw7nztCb6Y+81iVx6H-_yE3cGswK+LpQ@mail.gmail.com>
Message-ID: <5170438B.9040309@gemini.edu>

Good.

Tim Pickering also said that "something like scipy.optimize.fmin_powell"
will handle vectors of coefficients so you can vectorize the whole thing
but I think he forgot to copy you...

James.


On 18/04/13 15:00, Joe Philip Ninan wrote:
> Hi James,
> I think i shall try to keep the code as much pure python as possible. Installing
> iraf on the controller machine just for one routine will probably be an over kill.
> Nadia sent me link to pull request of astropy which can do fitting on 2d array.
> So i only have to flatten by 3d to a 2d, with time along the column. (
> https://github.com/astropy/astropy/pull/493 ).
> This isn't merged to astropy yet, but i was told it will be merged soon.
> Thanks for the suggestions,
> -cheers
> joe
>
>
> On 18 April 2013 22:49, James Turner <jturner at gemini.edu
> <mailto:jturner at gemini.edu>> wrote:
>
>      > But I couldn't find anything for fitting a polynomial for every pixel
>     along an
>      > axis of an ndarray.
>      > Is there a tool to do this? Without implementing a python loop to loop
>     through
>      > each pixel and calculate coefficients?
>
>     I'm not sure if there is anything yet (could tell you how to do
>     it in IRAF), as I think fitting has been a bit of a missing area
>     in Python until some recent work-in-progress. But wouldn't it
>     help to use Cython? I was also wondering whether a Python loop
>     will really be that slow if you're doing something relatively
>     non-trivial like a fit, but it probably will be since the axis
>     you're fitting will be much shorter than the image size...
>
>     Cheers,
>
>     James.
>
>
>      > Worst case scenario, i think i will have to write a C routine to do
>     polynomial
>      > fit and call it from python. But i would really love if a pure python
>      > alternative exists.
>      >
>      > Thanks
>      > -cheers
>      > joe
>      >
>      >
>      >
>      >
>      >
>      > --
>      > /---------------------------------------------------------------
>      > "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>      >
>      > ************************************************
>      > Joe Philip Ninan http://sites.google.com/site/jpninan/
>      > Research Scholar        /________________\
>      > DAA,                            | Vadakeparambil |
>      > TIFR,                           | Pullad P.O.         |
>      > Mumbai-05, India.      | Kerala, India      |
>      > Ph: +917738438212   | PIN:689548       |
>      > ------------------------------\_______________/--------------
>      >
>      >
>      > _______________________________________________
>      > 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
>
>
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------



From aldcroft at head.cfa.harvard.edu  Thu Apr 18 15:32:11 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Thu, 18 Apr 2013 15:32:11 -0400
Subject: [AstroPy] SOFA license letter (draft)
Message-ID: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>

Following the long and useful discussion in the "astropy in Debian,
Scientific Linux" thread, I have taken a crack at drafting a letter that
can be used as the basis for discussion with SOFA board members or other
colleagues with influence.  It is also written somewhat in the form of a
petition.

This is just a draft, but I wanted to get the ball rolling.  It would be
very helpful if other affected parties (package managers, people with SOFA
dependencies) can pitch in with more details.  In particular there are two
open sections that I would hope Sergio and Ole can work on.

https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community

I think anyone with a github account can edit, but let me know otherwise.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130418/4a21d6cd/attachment.html>

From beaumont at hawaii.edu  Thu Apr 18 15:33:28 2013
From: beaumont at hawaii.edu (Chris Beaumont)
Date: Thu, 18 Apr 2013 15:33:28 -0400
Subject: [AstroPy] Linearity correction by polynomial fitting
In-Reply-To: <5170438B.9040309@gemini.edu>
References: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
	<51702B25.2050701@gemini.edu>
	<CAJ_T+b69AyVtQ_DHgwVw7nztCb6Y+81iVx6H-_yE3cGswK+LpQ@mail.gmail.com>
	<5170438B.9040309@gemini.edu>
Message-ID: <CAFP9tKraQb4i=MpNN9+23wjsXm5Tu97W2Xn2=osQb_QNsY-jcQ@mail.gmail.com>

Hi Joe,

The astropy PR is good to know about -- keep me posted about what you
discover!

Fitting all ~3-5 million polynomial coefficients at once sounds like a bad
idea to me. The complexity of OLS increases roughly with ~coefficients^1-3
(depending on the method), so a single fit to 5-million unknowns is *much*
more computationally intensive than a million fits to 5-unknowns.

chris


On Thu, Apr 18, 2013 at 3:03 PM, James Turner <jturner at gemini.edu> wrote:

> Good.
>
> Tim Pickering also said that "something like scipy.optimize.fmin_powell"
> will handle vectors of coefficients so you can vectorize the whole thing
> but I think he forgot to copy you...
>
> James.
>
>
> On 18/04/13 15:00, Joe Philip Ninan wrote:
> > Hi James,
> > I think i shall try to keep the code as much pure python as possible.
> Installing
> > iraf on the controller machine just for one routine will probably be an
> over kill.
> > Nadia sent me link to pull request of astropy which can do fitting on 2d
> array.
> > So i only have to flatten by 3d to a 2d, with time along the column. (
> > https://github.com/astropy/astropy/pull/493 ).
> > This isn't merged to astropy yet, but i was told it will be merged soon.
> > Thanks for the suggestions,
> > -cheers
> > joe
> >
> >
> > On 18 April 2013 22:49, James Turner <jturner at gemini.edu
> > <mailto:jturner at gemini.edu>> wrote:
> >
> >      > But I couldn't find anything for fitting a polynomial for every
> pixel
> >     along an
> >      > axis of an ndarray.
> >      > Is there a tool to do this? Without implementing a python loop to
> loop
> >     through
> >      > each pixel and calculate coefficients?
> >
> >     I'm not sure if there is anything yet (could tell you how to do
> >     it in IRAF), as I think fitting has been a bit of a missing area
> >     in Python until some recent work-in-progress. But wouldn't it
> >     help to use Cython? I was also wondering whether a Python loop
> >     will really be that slow if you're doing something relatively
> >     non-trivial like a fit, but it probably will be since the axis
> >     you're fitting will be much shorter than the image size...
> >
> >     Cheers,
> >
> >     James.
> >
> >
> >      > Worst case scenario, i think i will have to write a C routine to
> do
> >     polynomial
> >      > fit and call it from python. But i would really love if a pure
> python
> >      > alternative exists.
> >      >
> >      > Thanks
> >      > -cheers
> >      > joe
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > --
> >      > /---------------------------------------------------------------
> >      > "GNU/Linux: because a PC is a terrible thing to waste" -  GNU
> Generation
> >      >
> >      > ************************************************
> >      > Joe Philip Ninan http://sites.google.com/site/jpninan/
> >      > Research Scholar        /________________\
> >      > DAA,                            | Vadakeparambil |
> >      > TIFR,                           | Pullad P.O.         |
> >      > Mumbai-05, India.      | Kerala, India      |
> >      > Ph: +917738438212   | PIN:689548       |
> >      > ------------------------------\_______________/--------------
> >      >
> >      >
> >      > _______________________________________________
> >      > 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
> >
> >
> >
> >
> > --
> > /---------------------------------------------------------------
> > "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
> >
> > ************************************************
> > Joe Philip Ninan http://sites.google.com/site/jpninan/
> > Research Scholar        /________________\
> > DAA,                            | Vadakeparambil |
> > TIFR,                           | Pullad P.O.         |
> > Mumbai-05, India.      | Kerala, India      |
> > Ph: +917738438212   | PIN:689548       |
> > ------------------------------\_______________/--------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130418/e7b4832f/attachment.html>

From npkuin at gmail.com  Thu Apr 18 16:07:14 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Thu, 18 Apr 2013 21:07:14 +0100
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
Message-ID: <CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>

Hi Tom,

That is sort of what was discussed.

I must admit that in my mind it is completely unclear why it was declared
non-free.  It does allow others its use, and the conditions are mostly in
the area of intellectual property, specifically that the software as
distributed is that of the IAU, and misrepresentation of the software or
alteration must be clearly delineated from that of the IAU. I do not think
that comes under the guise of "non-free".  "Free" does not mean "I take it
and tag my name onto it", it does not mean " I alter it and say it was made
by you ", I think that the problem is rather in the software distributors
assignment which is to blame. Focussing only on the SOFA WG is not going to
solve this. I think there needs to be a discussion of all parties involved.
 It would be good if the aim of the petition would be to get the parties
talking.

Cheers,

   Paul


On Thu, Apr 18, 2013 at 8:32 PM, Tom Aldcroft <aldcroft at head.cfa.harvard.edu
> wrote:

> Following the long and useful discussion in the "astropy in Debian,
> Scientific Linux" thread, I have taken a crack at drafting a letter that
> can be used as the basis for discussion with SOFA board members or other
> colleagues with influence.  It is also written somewhat in the form of a
> petition.
>
> This is just a draft, but I wanted to get the ball rolling.  It would be
> very helpful if other affected parties (package managers, people with SOFA
> dependencies) can pitch in with more details.  In particular there are two
> open sections that I would hope Sergio and Ole can work on.
>
> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
>
> I think anyone with a github account can edit, but let me know otherwise.
>
> Cheers,
> Tom
>
>
>
> _______________________________________________
> 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/20130418/a4b029cf/attachment.html>

From stsci.perry at gmail.com  Thu Apr 18 16:13:36 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Thu, 18 Apr 2013 16:13:36 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
Message-ID: <519E6830-6E7D-4547-9621-472A9A517309@gmail.com>

It's not so simple as that. You have to read and understand the terms of the GPL to see that there are clauses in the SOFA license that are not permitted by the GPL. Some of these are somewhat a matter of interpretation, but it's the interpretation of those that package it that particularly matters. I've heard the opinon now a few times that it's the other parties that have to accomodate the SOFA license. It's not going to happen. SOFA is a speck of dust in that universe. It doesn't even rise to the level of a tail wagging the dog.

Perry

On Apr 18, 2013, at 4:07 PM, Paul Kuin wrote:

> Hi Tom, 
> 
> That is sort of what was discussed. 
> 
> I must admit that in my mind it is completely unclear why it was declared non-free.  It does allow others its use, and the conditions are mostly in the area of intellectual property, specifically that the software as distributed is that of the IAU, and misrepresentation of the software or alteration must be clearly delineated from that of the IAU. I do not think that comes under the guise of "non-free".  "Free" does not mean "I take it and tag my name onto it", it does not mean " I alter it and say it was made by you ", I think that the problem is rather in the software distributors assignment which is to blame. Focussing only on the SOFA WG is not going to solve this. I think there needs to be a discussion of all parties involved.  It would be good if the aim of the petition would be to get the parties talking.  
> 
> Cheers, 
> 
>    Paul
> 
> 
> On Thu, Apr 18, 2013 at 8:32 PM, Tom Aldcroft <aldcroft at head.cfa.harvard.edu> wrote:
> Following the long and useful discussion in the "astropy in Debian, Scientific Linux" thread, I have taken a crack at drafting a letter that can be used as the basis for discussion with SOFA board members or other colleagues with influence.  It is also written somewhat in the form of a petition.
> 
> This is just a draft, but I wanted to get the ball rolling.  It would be very helpful if other affected parties (package managers, people with SOFA dependencies) can pitch in with more details.  In particular there are two open sections that I would hope Sergio and Ole can work on.
> 
> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
> 
> I think anyone with a github account can edit, but let me know otherwise.
> 
> Cheers,
> Tom
> 
> 
> 
> _______________________________________________
> 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.
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From stsci.perry at gmail.com  Thu Apr 18 16:22:55 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Thu, 18 Apr 2013 16:22:55 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
Message-ID: <4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>

just to resurrect one of the emails with specifics: http://lists.fedoraproject.org/pipermail/legal/2012-November/002044.html

Richard Fontana rfontana at redhat.com 
Thu Nov 29 00:39:51 UTC 2012
	? Previous message: [Fedora-legal-list] SOFA software license
	? Next message: [Fedora-legal-list] SciTech MGL Public License Version 1.0
	? Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Nov 28, 2012 at 06:03:16PM -0600, Jason L Tibbitts III wrote:
> >>>>> "TC" == Tom Callaway <tcallawa at redhat.com
> writes:
>
> TC> It is not, this license is non-free because of clause 3c.
> 
> My curiosity requires that I ask if clause 4 is field of use
> restriction:
>
> 4. You shall not cause the SOFA software to be brought into disrepute,
>    either by misuse, or use for inappropriate tasks, or by inappropriate
>    modification.

Oh, I think spot and I both didn't even get to that part. Certainly,
that's an even bigger problem.

 - RF

*********

So don't get hung up on what "free" means. It really is an issue of whether their license can be made compatible with the GPL.

On Apr 18, 2013, at 4:13 PM, Perry Greenfield wrote:

> It's not so simple as that. You have to read and understand the terms of the GPL to see that there are clauses in the SOFA license that are not permitted by the GPL. Some of these are somewhat a matter of interpretation, but it's the interpretation of those that package it that particularly matters. I've heard the opinon now a few times that it's the other parties that have to accomodate the SOFA license. It's not going to happen. SOFA is a speck of dust in that universe. It doesn't even rise to the level of a tail wagging the dog.
> 
> Perry
> 
> On Apr 18, 2013, at 4:07 PM, Paul Kuin wrote:
> 
>> Hi Tom, 
>> 
>> That is sort of what was discussed. 
>> 
>> I must admit that in my mind it is completely unclear why it was declared non-free.  It does allow others its use, and the conditions are mostly in the area of intellectual property, specifically that the software as distributed is that of the IAU, and misrepresentation of the software or alteration must be clearly delineated from that of the IAU. I do not think that comes under the guise of "non-free".  "Free" does not mean "I take it and tag my name onto it", it does not mean " I alter it and say it was made by you ", I think that the problem is rather in the software distributors assignment which is to blame. Focussing only on the SOFA WG is not going to solve this. I think there needs to be a discussion of all parties involved.  It would be good if the aim of the petition would be to get the parties talking.  
>> 
>> Cheers, 
>> 
>>   Paul
>> 
>> 
>> On Thu, Apr 18, 2013 at 8:32 PM, Tom Aldcroft <aldcroft at head.cfa.harvard.edu> wrote:
>> Following the long and useful discussion in the "astropy in Debian, Scientific Linux" thread, I have taken a crack at drafting a letter that can be used as the basis for discussion with SOFA board members or other colleagues with influence.  It is also written somewhat in the form of a petition.
>> 
>> This is just a draft, but I wanted to get the ball rolling.  It would be very helpful if other affected parties (package managers, people with SOFA dependencies) can pitch in with more details.  In particular there are two open sections that I would hope Sergio and Ole can work on.
>> 
>> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
>> 
>> I think anyone with a github account can edit, but let me know otherwise.
>> 
>> Cheers,
>> Tom
>> 
>> 
>> 
>> _______________________________________________
>> 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.
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> 



From thomas.robitaille at gmail.com  Thu Apr 18 16:26:39 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 18 Apr 2013 22:26:39 +0200
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
Message-ID: <CAGMHX_2a6Axp+dKPEm7R3nNgs4bC-i7smos-GD+56928jTdVuA@mail.gmail.com>

On 18 April 2013 22:07, Paul Kuin <npkuin at gmail.com> wrote:
> Hi Tom,
>
> That is sort of what was discussed.
>
> I must admit that in my mind it is completely unclear why it was declared
> non-free.  It does allow others its use, and the conditions are mostly in
> the area of intellectual property, specifically that the software as
> distributed is that of the IAU, and misrepresentation of the software or
> alteration must be clearly delineated from that of the IAU. I do not think
> that comes under the guise of "non-free".  "Free" does not mean "I take it
> and tag my name onto it", it does not mean " I alter it and say it was made
> by you ", I think that the problem is rather in the software distributors

Not that we should start a long debate on the license since this has
been debated before, but consider for example the following clause:

"You shall not cause the SOFA software to be brought into disrepute,
either by misuse, or use for inappropriate tasks, or by inappropriate
modification."

Define 'disrepute' and 'inappropriate' - basically if the SOFA board
decide at any point that they don't like what Astropy is doing with
SOFA, or that someone uses Astropy for 'inappropriate uses', they
could claim that we are bringing SOFA into disrepute or using it
'inappropriately', since those are not well defined terms, and declare
that we are not allowed to use it. This is what is meant by non-free -
they can revoke our license to use it anytime. Those terms are
completely subjective.

Cheers,
Tom

> assignment which is to blame. Focussing only on the SOFA WG is not going to
> solve this. I think there needs to be a discussion of all parties involved.
> It would be good if the aim of the petition would be to get the parties
> talking.
>
> Cheers,
>
>    Paul
>
>
> On Thu, Apr 18, 2013 at 8:32 PM, Tom Aldcroft
> <aldcroft at head.cfa.harvard.edu> wrote:
>>
>> Following the long and useful discussion in the "astropy in Debian,
>> Scientific Linux" thread, I have taken a crack at drafting a letter that can
>> be used as the basis for discussion with SOFA board members or other
>> colleagues with influence.  It is also written somewhat in the form of a
>> petition.
>>
>> This is just a draft, but I wanted to get the ball rolling.  It would be
>> very helpful if other affected parties (package managers, people with SOFA
>> dependencies) can pitch in with more details.  In particular there are two
>> open sections that I would hope Sergio and Ole can work on.
>>
>> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
>>
>> I think anyone with a github account can edit, but let me know otherwise.
>>
>> Cheers,
>> Tom
>>
>>
>>
>> _______________________________________________
>> 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.
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From thomas.robitaille at gmail.com  Thu Apr 18 16:29:47 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 18 Apr 2013 22:29:47 +0200
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
Message-ID: <CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>

On 18 April 2013 21:32, Tom Aldcroft <aldcroft at head.cfa.harvard.edu> wrote:
> Following the long and useful discussion in the "astropy in Debian,
> Scientific Linux" thread, I have taken a crack at drafting a letter that can
> be used as the basis for discussion with SOFA board members or other
> colleagues with influence.  It is also written somewhat in the form of a
> petition.
>
> This is just a draft, but I wanted to get the ball rolling.  It would be
> very helpful if other affected parties (package managers, people with SOFA
> dependencies) can pitch in with more details.  In particular there are two
> open sections that I would hope Sergio and Ole can work on.
>
> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
>
> I think anyone with a github account can edit, but let me know otherwise.

In terms of alternatives, I see the following (in terms of
'standards') that we could suggest:

- Public Domain
- MIT or BSD license

Does anyone know for sure if the LGPL is BSD-compatible? If so, that's
another option.

Cheers,
Tom


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


From jniehof at lanl.gov  Thu Apr 18 16:37:02 2013
From: jniehof at lanl.gov (Jonathan T. Niehof)
Date: Thu, 18 Apr 2013 14:37:02 -0600
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CAGMHX_2a6Axp+dKPEm7R3nNgs4bC-i7smos-GD+56928jTdVuA@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<CAGMHX_2a6Axp+dKPEm7R3nNgs4bC-i7smos-GD+56928jTdVuA@mail.gmail.com>
Message-ID: <5170596E.6000001@lanl.gov>

On 04/18/2013 02:26 PM, Thomas Robitaille wrote:
> "You shall not cause the SOFA software to be brought into disrepute,
> either by misuse, or use for inappropriate tasks, or by inappropriate
> modification."

Reminds me of the "software shall be used for good" problem:
http://wonko.com/post/jsmin-isnt-welcome-on-google-code

Being cute in license agreements usually causes headaches.

I agree that petitioning from the community is a good idea. It may be 
worth including the track record of existing licenses. As 
very-much-not-a-lawyer, boilerplate contracts with history make me 
happier. Thanks for the draft, Tom.

-- 
Jonathan Niehof
ISR-3 Space Data Systems
Los Alamos National Laboratory
MS-D466
Los Alamos, NM 87545

Phone: 505-667-9595
email: jniehof at lanl.gov

Correspondence /
Technical data or Software Publicly Available


From npkuin at gmail.com  Thu Apr 18 17:06:29 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Thu, 18 Apr 2013 22:06:29 +0100
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
	<4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
Message-ID: <CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>

Hi Perry,

I agree that it is not free in that sense. I see it as a control issue,
which may come from concerns about versions of modified software
circulating which would include changes that are in conflict with the
international system.

However, it seems like one can make essentially a copy by changing the
names of the functions, etc., add a description of the changes, state the
origin of the basis of the software, and ad a GPL license. Or did I miss
something?

Cheers,

   Paul





On Thu, Apr 18, 2013 at 9:22 PM, Perry Greenfield <stsci.perry at gmail.com>wrote:

> just to resurrect one of the emails with specifics:
> http://lists.fedoraproject.org/pipermail/legal/2012-November/002044.html
>
> Richard Fontana rfontana at redhat.com
> Thu Nov 29 00:39:51 UTC 2012
>         ? Previous message: [Fedora-legal-list] SOFA software license
>         ? Next message: [Fedora-legal-list] SciTech MGL Public License
> Version 1.0
>         ? Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> On Wed, Nov 28, 2012 at 06:03:16PM -0600, Jason L Tibbitts III wrote:
> > >>>>> "TC" == Tom Callaway <tcallawa at redhat.com
> > writes:
> >
> > TC> It is not, this license is non-free because of clause 3c.
> >
> > My curiosity requires that I ask if clause 4 is field of use
> > restriction:
> >
> > 4. You shall not cause the SOFA software to be brought into disrepute,
> >    either by misuse, or use for inappropriate tasks, or by inappropriate
> >    modification.
>
> Oh, I think spot and I both didn't even get to that part. Certainly,
> that's an even bigger problem.
>
>  - RF
>
> *********
>
> So don't get hung up on what "free" means. It really is an issue of
> whether their license can be made compatible with the GPL.
>
> On Apr 18, 2013, at 4:13 PM, Perry Greenfield wrote:
>
> > It's not so simple as that. You have to read and understand the terms of
> the GPL to see that there are clauses in the SOFA license that are not
> permitted by the GPL. Some of these are somewhat a matter of
> interpretation, but it's the interpretation of those that package it that
> particularly matters. I've heard the opinon now a few times that it's the
> other parties that have to accomodate the SOFA license. It's not going to
> happen. SOFA is a speck of dust in that universe. It doesn't even rise to
> the level of a tail wagging the dog.
> >
> > Perry
> >
> > On Apr 18, 2013, at 4:07 PM, Paul Kuin wrote:
> >
> >> Hi Tom,
> >>
> >> That is sort of what was discussed.
> >>
> >> I must admit that in my mind it is completely unclear why it was
> declared non-free.  It does allow others its use, and the conditions are
> mostly in the area of intellectual property, specifically that the software
> as distributed is that of the IAU, and misrepresentation of the software or
> alteration must be clearly delineated from that of the IAU. I do not think
> that comes under the guise of "non-free".  "Free" does not mean "I take it
> and tag my name onto it", it does not mean " I alter it and say it was made
> by you ", I think that the problem is rather in the software distributors
> assignment which is to blame. Focussing only on the SOFA WG is not going to
> solve this. I think there needs to be a discussion of all parties involved.
>  It would be good if the aim of the petition would be to get the parties
> talking.
> >>
> >> Cheers,
> >>
> >>   Paul
> >>
> >>
> >> On Thu, Apr 18, 2013 at 8:32 PM, Tom Aldcroft <
> aldcroft at head.cfa.harvard.edu> wrote:
> >> Following the long and useful discussion in the "astropy in Debian,
> Scientific Linux" thread, I have taken a crack at drafting a letter that
> can be used as the basis for discussion with SOFA board members or other
> colleagues with influence.  It is also written somewhat in the form of a
> petition.
> >>
> >> This is just a draft, but I wanted to get the ball rolling.  It would
> be very helpful if other affected parties (package managers, people with
> SOFA dependencies) can pitch in with more details.  In particular there are
> two open sections that I would hope Sergio and Ole can work on.
> >>
> >> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
> >>
> >> I think anyone with a github account can edit, but let me know
> otherwise.
> >>
> >> Cheers,
> >> Tom
> >>
> >>
> >>
> >> _______________________________________________
> >> 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.
> >> _______________________________________________
> >> 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/20130418/3e4fa6db/attachment.html>

From stsci.perry at gmail.com  Thu Apr 18 17:40:58 2013
From: stsci.perry at gmail.com (Perry Greenfield)
Date: Thu, 18 Apr 2013 17:40:58 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
	<4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
	<CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>
Message-ID: <145327F8-125B-45E8-91B8-AF0CE116FF33@gmail.com>


On Apr 18, 2013, at 5:06 PM, Paul Kuin wrote:

> Hi Perry,  
> 
> I agree that it is not free in that sense. I see it as a control issue, which may come from concerns about versions of modified software circulating which would include changes that are in conflict with the international system.  
> 
> However, it seems like one can make essentially a copy by changing the names of the functions, etc., add a description of the changes, state the origin of the basis of the software, and ad a GPL license. Or did I miss something?
> 
> Cheers, 
> 
>    Paul
> 
Well, to start IANAL :-)

So you're getting amateur legal opinions here.

Note the clause 3e:

These requirements must be reproduced intact in any source distribution and shall apply to anyone to whom you have granted a further right to modify the source code of your derived work.

So just by changing these things you don't remove the unacceptable part of the license. They basically are requiring you to propagate these terms regardless.

Perry

From aldcroft at head.cfa.harvard.edu  Thu Apr 18 19:02:27 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Thu, 18 Apr 2013 19:02:27 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <145327F8-125B-45E8-91B8-AF0CE116FF33@gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
	<4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
	<CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>
	<145327F8-125B-45E8-91B8-AF0CE116FF33@gmail.com>
Message-ID: <CAGsQ-Nu=S1TmDZ9gunhbY9U6cqDFvLTExvLdPGGi2dJmJgYJUA@mail.gmail.com>

On Thu, Apr 18, 2013 at 5:40 PM, Perry Greenfield <stsci.perry at gmail.com>wrote:

>
> On Apr 18, 2013, at 5:06 PM, Paul Kuin wrote:
>
> > Hi Perry,
> >
> > I agree that it is not free in that sense. I see it as a control issue,
> which may come from concerns about versions of modified software
> circulating which would include changes that are in conflict with the
> international system.
> >
> > However, it seems like one can make essentially a copy by changing the
> names of the functions, etc., add a description of the changes, state the
> origin of the basis of the software, and ad a GPL license. Or did I miss
> something?
> >
> > Cheers,
> >
> >    Paul
> >
> Well, to start IANAL :-)
>
> So you're getting amateur legal opinions here.
>
> Note the clause 3e:
>
> These requirements must be reproduced intact in any source distribution
> and shall apply to anyone to whom you have granted a further right to
> modify the source code of your derived work.
>
> So just by changing these things you don't remove the unacceptable part of
> the license. They basically are requiring you to propagate these terms
> regardless.
>

Yes, I spent a few minutes pondering the option of changing function names,
but clause 3e really disallows that.  Not to try to squelch interesting
discussions, but we have talked at length about how to get around the
existing license by email, telecon, and in person, and I don't think that
it is a fruitful avenue of discussion.  The fact is that people on the
debian-legal and fedora-legal lists have both declared that SOFA is
inconsistent with their requirements for packaging.  So that's pretty much
the end of the story unless someone here *IS* a lawyer and can successfully
convince Debian and Fedora that SOFA or some derivative can be packaged.

- Tom


>
> Perry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130418/c3cdeb52/attachment.html>

From sransom at nrao.edu  Thu Apr 18 19:24:37 2013
From: sransom at nrao.edu (Scott Ransom)
Date: Thu, 18 Apr 2013 18:24:37 -0500
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <145327F8-125B-45E8-91B8-AF0CE116FF33@gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
	<4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
	<CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>
	<145327F8-125B-45E8-91B8-AF0CE116FF33@gmail.com>
Message-ID: <517080B5.7080204@nrao.edu>

On 04/18/2013 04:40 PM, Perry Greenfield wrote:
>
> On Apr 18, 2013, at 5:06 PM, Paul Kuin wrote:
>
>> Hi Perry,
>>
>> I agree that it is not free in that sense. I see it as a control issue, which may come from concerns about versions of modified software circulating which would include changes that are in conflict with the international system.
>>
>> However, it seems like one can make essentially a copy by changing the names of the functions, etc., add a description of the changes, state the origin of the basis of the software, and ad a GPL license. Or did I miss something?
>>
>> Cheers,
>>
>>     Paul
>>
> Well, to start IANAL :-)
>
> So you're getting amateur legal opinions here.
>
> Note the clause 3e:
>
> These requirements must be reproduced intact in any source distribution and shall apply to anyone to whom you have granted a further right to modify the source code of your derived work.
>
> So just by changing these things you don't remove the unacceptable part of the license. They basically are requiring you to propagate these terms regardless.
>
> Perry

Hi All,

I _may_ become the newest member of the SOFA board very soon...  I was 
in contact with one of the current members as well as the Chair over the 
past week and mentioned several times problems with the license.

If I do become a member, fixing the license (probably requesting that 
they simply make it BSD or maybe LGPL?) will be one of the first things 
that I pound on.

I really like the idea of astropy using SOFA under the hood if at all 
possible...

Scott


-- 
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 jturner at gemini.edu  Thu Apr 18 21:02:26 2013
From: jturner at gemini.edu (James Turner)
Date: Thu, 18 Apr 2013 21:02:26 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>
Message-ID: <517097A2.9010208@gemini.edu>

> Does anyone know for sure if the LGPL is BSD-compatible? If so, that's
> another option.
>
> Cheers,
> Tom

I'm a bit fuzzy on the details, apart from not being a lawyer etc,
but I believe that (as for the GPL) there's nothing to prevent you
combining them as long as you are prepared to follow the more
restrictive terms of the LGPL for the combination. Unlike the GPL,
those terms do allow your combined "work that uses the Library" to
have a different licence, which I believe means that downstream
recipients could still make a proprietary version of AstroPy, as
you deliberately allow them to with BSD -- but they would have to
release source code for any changes they make to the LGPL library
itself (in this case SOFA) under the LGPL.

A proprietary work based on AstroPy would also have to allow
relinking to a modified version of the LGPL library, which I
presume with Python would just mean (re)distributing the wrapper
code to make the Python .so module (or some object file version of
that wrapper). There are also a couple of requirements to include
notices about the dependency.

I see that SciPy does NOT accept LGPL code though, suggesting
that the business interests behind it have thought of some less
obvious angle (maybe they don't like the obligation to provide
source for LGPL dependencies or wrapper code; their reasoning is
simply that "the license of the code should not have more
restrictions than [BSD]"):

   http://www.scipy.org/License_Compatibility

I haven't thought hard about what constitutes a derivative work in
Python generally, when there's no difference between source and
executables (other than pyc files). Under some circumstances you
might be able to satisfy the GPL itself in the same way as LGPL,
but that would need further investigation; there seems to be some
general contention and legal greyness about what makes a
derivative work where dynamic linking is involved (eg. the painful
Linux kernel graphics drivers), so that can only apply even more
to Python.

Cheers,

James.



From astropy at liska.ath.cx  Fri Apr 19 01:37:14 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Fri, 19 Apr 2013 07:37:14 +0200
Subject: [AstroPy] SOFA license letter (draft)
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
	<4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
	<CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>
Message-ID: <87zjwv6pyt.fsf@news.ole.ath.cx>

Hi Paul,

Paul Kuin <npkuin at gmail.com> writes:
> However, it seems like one can make essentially a copy by changing the
> names of the functions, etc., add a description of the changes, state
> the origin of the basis of the software

In fact, this is one of the modifications I think about. One can then
even create a header file ("#define iauFunc whatever_Func") to reach
source code compatibility, and release the header file under PD or
BSD. From the license terms this is legal and would effectively remove
its ? 3c.

This example again shows that the community could feel forced to work
against the intention of the SOFA license while formally obeying it.

And, the "no discrimination of use" problem (? 4) is still effective
in the changed license.

Cheers

Ole


From astropy at liska.ath.cx  Fri Apr 19 03:20:31 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Fri, 19 Apr 2013 09:20:31 +0200
Subject: [AstroPy] SOFA license letter (draft)
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>
	<517097A2.9010208@gemini.edu>
Message-ID: <ytz1ua7asw0.fsf@news.ole.ath.cx>

James Turner <jturner at gemini.edu> writes:
> I haven't thought hard about what constitutes a derivative work in
> Python generally, when there's no difference between source and
> executables (other than pyc files).

What about modules that include C code?

Best

Ole


From sergio.pasra at gmail.com  Fri Apr 19 06:31:10 2013
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Fri, 19 Apr 2013 12:31:10 +0200
Subject: [AstroPy] Linearity correction by polynomial fitting
In-Reply-To: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
References: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
Message-ID: <CACta-KYHea38tiZZs8F_hzoPw_X5W+d5ejo0H73_0w9zL-HuxQ@mail.gmail.com>

You can use numpy.nditer to loop over the array efficiently, have a look here:

http://docs.scipy.org/doc/numpy/reference/arrays.nditer.html

If "data" is your data cube and "my_fitting_function" is a function
that takes a 1D array and returns a number,
the following code collapses your 3d array into a 2d array "result"

    it = numpy.nditer([data, None],
            flags=['reduce_ok', 'external_loop'],
            op_flags=[['readonly'], ['readwrite', 'allocate']],
            op_axes=[None, [0, 1, -1])
    it.operands[1][...] = 0

    for x, y in it:
        y[...] = my_fitting_function(x)

    result = it.operands[1]

This is slow, but not as slow as looping directly over data.
Furthermore, nditer handles dynamic allocation
of arrays and casting. And the C API is similar, so translating to
Numpy C (which is way faster) is straightforward.


Regards, Sergio

2013/4/18 Joe Philip Ninan <indiajoe at gmail.com>
>
> Hi,
>
> Context:
> I have a data cube, which is from an up-the-ramp readout of a detector.
> (i.e. data cube with the axis X pixel,Y pixel and Time)
> In order to fit a linearity correction function which maps from detector counts to actual count, I was planning to fit a straight line on the time axis (for each pixel), upto a threshold and then fit a 2 or 3 degree polynomial to map the difference between the extrapolated straight line and the non-linear counts of the pixel above the threshold (till it hits hard saturation).
>
> Now, the issue: [I want to avoid any python loops.]
> Calculating the slope and difference could be easily implemented by numpy masked array multiplications and other ndarray arithmetic.
> But I couldn't find anything for fitting a polynomial for every pixel along an axis of an ndarray.
> Is there a tool to do this? Without implementing a python loop to loop through each pixel and calculate coefficients?
> Worst case scenario, i think i will have to write a C routine to do polynomial fit and call it from python. But i would really love if a pure python alternative exists.
>
> Thanks
> -cheers
> joe
>
>
>
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan    http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From aldcroft at head.cfa.harvard.edu  Fri Apr 19 07:35:58 2013
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Fri, 19 Apr 2013 07:35:58 -0400
Subject: [AstroPy] Linearity correction by polynomial fitting
In-Reply-To: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
References: <CAJ_T+b7cSeB1MvDApVRYhLmeQi2a7ABu05jFz3EZ8DVA_yKTsw@mail.gmail.com>
Message-ID: <CAGsQ-NvpU0oKXhkA9vm5C8mtFhm4WQGkzYXZWnVKxZGKot=Hvg@mail.gmail.com>

On Thu, Apr 18, 2013 at 11:34 AM, Joe Philip Ninan <indiajoe at gmail.com>wrote:

> Hi,
>
> Context:
> I have a data cube, which is from an up-the-ramp readout of a detector.
> (i.e. data cube with the axis X pixel,Y pixel and Time)
> In order to fit a linearity correction function which maps from detector
> counts to actual count, I was planning to fit a straight line on the time
> axis (for each pixel), upto a threshold and then fit a 2 or 3 degree
> polynomial to map the difference between the extrapolated straight line and
> the non-linear counts of the pixel above the threshold (till it hits hard
> saturation).
>
> Now, the issue: [I want to avoid any python loops.]
> Calculating the slope and difference could be easily implemented by numpy
> masked array multiplications and other ndarray arithmetic.
> But I couldn't find anything for fitting a polynomial for every pixel
> along an axis of an ndarray.
> Is there a tool to do this? Without implementing a python loop to loop
> through each pixel and calculate coefficients?
> Worst case scenario, i think i will have to write a C routine to do
> polynomial fit and call it from python. But i would really love if a pure
> python alternative exists.
>

One thing to keep in mind is avoiding premature optimization and using
profiling to determine exactly where things are slow.  You could first code
it up in pure python loops and then see where the time is being spent.

In this case the best tool is line_profiler (
http://pypi.python.org/pypi/line_profiler).  If you worry about speed you
should immediately get proficient with this excellent tool as well as
cProfile.

Note that if your time axis is 100 elements long, dong a 3rd order
polynomial fit with np.polyfit is relatively slow (320 us on my mac).  The
python loops around this will be negligible, so just writing simple nested
loops around this will be fine.  (Apologies if I'm misunderstanding your
exact problem).

Cheers,
Tom


>
> Thanks
> -cheers
> joe
>
>
>
>
>
> --
> /---------------------------------------------------------------
> "GNU/Linux: because a PC is a terrible thing to waste" -  GNU Generation
>
> ************************************************
> Joe Philip Ninan    http://sites.google.com/site/jpninan/
> Research Scholar        /________________\
> DAA,                            | Vadakeparambil |
> TIFR,                           | Pullad P.O.         |
> Mumbai-05, India.      | Kerala, India      |
> Ph: +917738438212   | PIN:689548       |
> ------------------------------\_______________/--------------
>
> _______________________________________________
> 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/20130419/1e392f5c/attachment.html>

From mdroe at stsci.edu  Fri Apr 19 10:58:56 2013
From: mdroe at stsci.edu (Michael Droettboom)
Date: Fri, 19 Apr 2013 10:58:56 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>
Message-ID: <51715BB0.2050103@stsci.edu>

On 04/18/2013 04:29 PM, Thomas Robitaille wrote:
> On 18 April 2013 21:32, Tom Aldcroft <aldcroft at head.cfa.harvard.edu> wrote:
>> Following the long and useful discussion in the "astropy in Debian,
>> Scientific Linux" thread, I have taken a crack at drafting a letter that can
>> be used as the basis for discussion with SOFA board members or other
>> colleagues with influence.  It is also written somewhat in the form of a
>> petition.
>>
>> This is just a draft, but I wanted to get the ball rolling.  It would be
>> very helpful if other affected parties (package managers, people with SOFA
>> dependencies) can pitch in with more details.  In particular there are two
>> open sections that I would hope Sergio and Ole can work on.
>>
>> https://github.com/astropy/astropy/wiki/SOFA-license-for-the-community
>>
>> I think anyone with a github account can edit, but let me know otherwise.
> In terms of alternatives, I see the following (in terms of
> 'standards') that we could suggest:
>
> - Public Domain
> - MIT or BSD license
>
> Does anyone know for sure if the LGPL is BSD-compatible? If so, that's
> another option.
>
One license that seems to match IAU's intent here is the TeX license, 
which basically says "it's in the public domain, do what you like with 
it, as long as any modified version is not called TeX."

http://en.wikipedia.org/wiki/TeX#License

I throw it out there, just because it's well established that that kind 
of licensing is acceptable to Debian, Fedora and the like.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130419/cf053f2b/attachment.html>

From erik.tollerud at gmail.com  Sat Apr 20 16:47:53 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Sat, 20 Apr 2013 16:47:53 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <517080B5.7080204@nrao.edu>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CANoQ6N0PchhrzYdTFgUW2biMbAxKicGTYJpr4MROpiGYgpbEEw@mail.gmail.com>
	<519E6830-6E7D-4547-9621-472A9A517309@gmail.com>
	<4FE07B99-186E-4706-9350-5FC1A649085D@gmail.com>
	<CANoQ6N2Zi0+OMQVPbcLbicPyuCsKuXzgJEZWn=HuTAyYNOtncw@mail.gmail.com>
	<145327F8-125B-45E8-91B8-AF0CE116FF33@gmail.com>
	<517080B5.7080204@nrao.edu>
Message-ID: <CAARXUwVwJY4FGrDG6zUtF3Zf-55pMm7AjLW2UtiSkRF8k+X5ng@mail.gmail.com>

> I _may_ become the newest member of the SOFA board very soon...  I was
> in contact with one of the current members as well as the Chair over the
> past week and mentioned several times problems with the license.
>
> If I do become a member, fixing the license (probably requesting that
> they simply make it BSD or maybe LGPL?) will be one of the first things
> that I pound on.
>
> I really like the idea of astropy using SOFA under the hood if at all
> possible...

I for one certainly wish you the best of luck!

Note else there is a time pressure of sorts, because if this doesn't
happen for (say) a year, we probably will have already re-implemented
what we need from it.  So after that, we probably wouldn't end up
using it anyway.







--
Erik


From jturner at gemini.edu  Sat Apr 20 22:06:59 2013
From: jturner at gemini.edu (James Turner)
Date: Sat, 20 Apr 2013 22:06:59 -0400
Subject: [AstroPy] SOFA license letter (draft)
In-Reply-To: <ytz1ua7asw0.fsf@news.ole.ath.cx>
References: <CAGsQ-Nvsqw5YbHn3+WoM4Gk1F_xUSNeTLeQt-yVomNmn4ULPOg@mail.gmail.com>
	<CAGMHX_2dNCccUT7iD8UCQZh71X4_Kg7TNQ6BebxWqeB9MScr1Q@mail.gmail.com>
	<517097A2.9010208@gemini.edu> <ytz1ua7asw0.fsf@news.ole.ath.cx>
Message-ID: <517349C3.7000207@gemini.edu>

>> I haven't thought hard about what constitutes a derivative work in
>> Python generally, when there's no difference between source and
>> executables (other than pyc files).
>
> What about modules that include C code?
>
> Best
>
> Ole

If the C code is statically linked in, then according to the
FSF the module would definitely be a derivative work. If it's
dynamically linked, it might depend on the details -- eg. can
the module still run if the dependency is not present and can
some alternative code implementing the same ABI satisfy the
dependency?. If you had an astrometry module linked to SOFA,
that would probably be a derivative work and I think probably
the Python application would be too (though the latter might
be debatable).

Cheers,

James.



From thomas.robitaille at gmail.com  Mon Apr 22 15:59:03 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 22 Apr 2013 21:59:03 +0200
Subject: [AstroPy] PyAVM 0.9.1 released
Message-ID: <CAGMHX_058rjLKk71mFX1KBXfncoBEFPjLf5qxONdz7BconNnJw@mail.gmail.com>

Hi everyone,

I am happy to announce the release of PyAVM 0.9.1! PyAVM is a
lightweight pure-Python package which can be used to represent AVM
meta-data, as well as read it from any images and write it to PNG/JPEG
files with no additional dependencies (i.e. no XMP or image libraries
are required):

http://astrofrog.github.io/pyavm/

For more information about the AVM standard, see:

http://virtualastronomy.org/avm_metadata.php

In this release, the code has been completely refactored (and includes
code from the python-avm-library package, thanks to Amit Kapadia). The
package should now be much more robust, as well as validate user
input.

Please let me know if you run into any issues!

Cheers,
Tom


From dnarayanan at as.arizona.edu  Tue Apr 23 14:47:24 2013
From: dnarayanan at as.arizona.edu (Desika Narayanan)
Date: Tue, 23 Apr 2013 11:47:24 -0700
Subject: [AstroPy] pip install issues
Message-ID: <CAMMxB+MvmYx0WQt0BjSSOWirO_9T0-WaD_Z_dYK33oEynwwVYA@mail.gmail.com>

Hey Team Astropy,

I'm having some issues installing astropy from pip (where it seems like
there's some SSL certificate problem) that I'm not sure how to fix.

I'm running Mountain Lion (OS X) and python version 2.7.3:

>>> import sys
>>> print sys.version
2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34)
[GCC 4.0.1 (Apple Inc. build 5493)]


When I do:

[longtrail:~] dnarayanan% pip install astropy

I get:

Downloading/unpacking astropy
  Could not fetch URL https://pypi.python.org/simple/astropy/: There was a
problem confirming the ssl certificate: <urlopen error [Errno 1]
_ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
message digest algorithm>
  Will skip URL https://pypi.python.org/simple/astropy/ when looking for
download links for astropy
  Could not fetch URL https://pypi.python.org/simple/: There was a problem
confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504:
error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest
algorithm>
  Will skip URL https://pypi.python.org/simple/ when looking for download
links for astropy
  Cannot fetch index base URL https://pypi.python.org/simple/
  Could not fetch URL https://pypi.python.org/simple/astropy/: There was a
problem confirming the ssl certificate: <urlopen error [Errno 1]
_ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
message digest algorithm>
  Will skip URL https://pypi.python.org/simple/astropy/ when looking for
download links for astropy
  Could not find any downloads that satisfy the requirement astropy
Cleaning up...
No distributions at all found for astropy




Thanks for any help

-desika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130423/5556197f/attachment.html>

From wkerzendorf at gmail.com  Tue Apr 23 14:49:26 2013
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Tue, 23 Apr 2013 14:49:26 -0400
Subject: [AstroPy] pip install issues
In-Reply-To: <CAMMxB+MvmYx0WQt0BjSSOWirO_9T0-WaD_Z_dYK33oEynwwVYA@mail.gmail.com>
References: <CAMMxB+MvmYx0WQt0BjSSOWirO_9T0-WaD_Z_dYK33oEynwwVYA@mail.gmail.com>
Message-ID: <44421849-232A-4477-B812-5DB36EC60B41@gmail.com>

Are you running the enthought package by any chance?

Cheers
   Team Astropy World Police
On 2013-04-23, at 2:47 PM, Desika Narayanan <dnarayanan at as.arizona.edu> wrote:

> Hey Team Astropy,
> 
> I'm having some issues installing astropy from pip (where it seems like there's some SSL certificate problem) that I'm not sure how to fix.  
> 
> I'm running Mountain Lion (OS X) and python version 2.7.3:
> 
> >>> import sys
> >>> print sys.version
> 2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34) 
> [GCC 4.0.1 (Apple Inc. build 5493)]
> 
> 
> When I do:
> 
> [longtrail:~] dnarayanan% pip install astropy
> 
> I get:
> 
> Downloading/unpacking astropy
>   Could not fetch URL https://pypi.python.org/simple/astropy/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm>
>   Will skip URL https://pypi.python.org/simple/astropy/ when looking for download links for astropy
>   Could not fetch URL https://pypi.python.org/simple/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm>
>   Will skip URL https://pypi.python.org/simple/ when looking for download links for astropy
>   Cannot fetch index base URL https://pypi.python.org/simple/
>   Could not fetch URL https://pypi.python.org/simple/astropy/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm>
>   Will skip URL https://pypi.python.org/simple/astropy/ when looking for download links for astropy
>   Could not find any downloads that satisfy the requirement astropy
> Cleaning up...
> No distributions at all found for astropy
> 
> 
> 
> 
> Thanks for any help
> 
> -desika
> 
> 
> _______________________________________________
> 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/20130423/022e9e29/attachment.html>

From dnarayanan at as.arizona.edu  Tue Apr 23 14:50:54 2013
From: dnarayanan at as.arizona.edu (Desika Narayanan)
Date: Tue, 23 Apr 2013 11:50:54 -0700
Subject: [AstroPy] pip install issues
In-Reply-To: <44421849-232A-4477-B812-5DB36EC60B41@gmail.com>
References: <CAMMxB+MvmYx0WQt0BjSSOWirO_9T0-WaD_Z_dYK33oEynwwVYA@mail.gmail.com>
	<44421849-232A-4477-B812-5DB36EC60B41@gmail.com>
Message-ID: <CAMMxB+M4jWo9Tb_sN7+DDLvDTKveFZrdo70GLwBjDN3rMqvy4g@mail.gmail.com>

Yep - exactly
-d

On Tue, Apr 23, 2013 at 11:49 AM, Wolfgang Kerzendorf <wkerzendorf at gmail.com
> wrote:

> Are you running the enthought package by any chance?
>
> Cheers
>     Team Astropy World Police
> On 2013-04-23, at 2:47 PM, Desika Narayanan <dnarayanan at as.arizona.edu>
> wrote:
>
> Hey Team Astropy,
>
> I'm having some issues installing astropy from pip (where it seems like
> there's some SSL certificate problem) that I'm not sure how to fix.
>
> I'm running Mountain Lion (OS X) and python version 2.7.3:
>
> >>> import sys
> >>> print sys.version
> 2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34)
> [GCC 4.0.1 (Apple Inc. build 5493)]
>
>
> When I do:
>
> [longtrail:~] dnarayanan% pip install astropy
>
> I get:
>
> Downloading/unpacking astropy
>   Could not fetch URL https://pypi.python.org/simple/astropy/: There was
> a problem confirming the ssl certificate: <urlopen error [Errno 1]
> _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
> message digest algorithm>
>   Will skip URL https://pypi.python.org/simple/astropy/ when looking for
> download links for astropy
>   Could not fetch URL https://pypi.python.org/simple/: There was a
> problem confirming the ssl certificate: <urlopen error [Errno 1]
> _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
> message digest algorithm>
>   Will skip URL https://pypi.python.org/simple/ when looking for download
> links for astropy
>   Cannot fetch index base URL https://pypi.python.org/simple/
>   Could not fetch URL https://pypi.python.org/simple/astropy/: There was
> a problem confirming the ssl certificate: <urlopen error [Errno 1]
> _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
> message digest algorithm>
>   Will skip URL https://pypi.python.org/simple/astropy/ when looking for
> download links for astropy
>   Could not find any downloads that satisfy the requirement astropy
> Cleaning up...
> No distributions at all found for astropy
>
>
>
>
> Thanks for any help
>
> -desika
>
>
> _______________________________________________
> 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/20130423/73aa07f3/attachment.html>

From wkerzendorf at gmail.com  Tue Apr 23 14:54:05 2013
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Tue, 23 Apr 2013 14:54:05 -0400
Subject: [AstroPy] pip install issues
In-Reply-To: <CAMMxB+M4jWo9Tb_sN7+DDLvDTKveFZrdo70GLwBjDN3rMqvy4g@mail.gmail.com>
References: <CAMMxB+MvmYx0WQt0BjSSOWirO_9T0-WaD_Z_dYK33oEynwwVYA@mail.gmail.com>
	<44421849-232A-4477-B812-5DB36EC60B41@gmail.com>
	<CAMMxB+M4jWo9Tb_sN7+DDLvDTKveFZrdo70GLwBjDN3rMqvy4g@mail.gmail.com>
Message-ID: <535F2BCD-0F2F-4738-8E55-ACD1AFFBA230@gmail.com>

Well, that is the problem - we've encountered that before. [My opinion which may not reflect the astropy community] Use macports instead - it seems to work much more reliably. 

Tom R says:
---
By the way, for anyone migrating from EPD to other solutions, you may
have to remove your .ipython folder first, as EPD uses a profile for
IPython that can cause an error with other Python distributions (saw
an example of that today). I can try and dig out more details if
anyone is interested.
---

Cheers
    Wolfgang

On 2013-04-23, at 2:50 PM, Desika Narayanan <dnarayanan at as.arizona.edu> wrote:

> Yep - exactly  
> -d
> 
> On Tue, Apr 23, 2013 at 11:49 AM, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:
> Are you running the enthought package by any chance?
> 
> Cheers
>    Team Astropy World Police
> On 2013-04-23, at 2:47 PM, Desika Narayanan <dnarayanan at as.arizona.edu> wrote:
> 
>> Hey Team Astropy,
>> 
>> I'm having some issues installing astropy from pip (where it seems like there's some SSL certificate problem) that I'm not sure how to fix.  
>> 
>> I'm running Mountain Lion (OS X) and python version 2.7.3:
>> 
>> >>> import sys
>> >>> print sys.version
>> 2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34) 
>> [GCC 4.0.1 (Apple Inc. build 5493)]
>> 
>> 
>> When I do:
>> 
>> [longtrail:~] dnarayanan% pip install astropy
>> 
>> I get:
>> 
>> Downloading/unpacking astropy
>>   Could not fetch URL https://pypi.python.org/simple/astropy/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm>
>>   Will skip URL https://pypi.python.org/simple/astropy/ when looking for download links for astropy
>>   Could not fetch URL https://pypi.python.org/simple/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm>
>>   Will skip URL https://pypi.python.org/simple/ when looking for download links for astropy
>>   Cannot fetch index base URL https://pypi.python.org/simple/
>>   Could not fetch URL https://pypi.python.org/simple/astropy/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm>
>>   Will skip URL https://pypi.python.org/simple/astropy/ when looking for download links for astropy
>>   Could not find any downloads that satisfy the requirement astropy
>> Cleaning up...
>> No distributions at all found for astropy
>> 
>> 
>> 
>> 
>> Thanks for any help
>> 
>> -desika
>> 
>> 
>> _______________________________________________
>> 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/20130423/ddcf0f9d/attachment.html>

From embray at stsci.edu  Tue Apr 23 16:02:28 2013
From: embray at stsci.edu (Erik Bray)
Date: Tue, 23 Apr 2013 16:02:28 -0400
Subject: [AstroPy] pip install issues
In-Reply-To: <535F2BCD-0F2F-4738-8E55-ACD1AFFBA230@gmail.com>
References: <CAMMxB+MvmYx0WQt0BjSSOWirO_9T0-WaD_Z_dYK33oEynwwVYA@mail.gmail.com>
	<44421849-232A-4477-B812-5DB36EC60B41@gmail.com>
	<CAMMxB+M4jWo9Tb_sN7+DDLvDTKveFZrdo70GLwBjDN3rMqvy4g@mail.gmail.com>
	<535F2BCD-0F2F-4738-8E55-ACD1AFFBA230@gmail.com>
Message-ID: <5176E8D4.4040501@stsci.edu>

On 04/23/2013 02:54 PM, Wolfgang Kerzendorf wrote:
> Well, that is the problem - we've encountered that before. [My opinion which may
> not reflect the astropy community] Use macports instead - it seems to work much
> more reliably.

I don't think that's a helpful solution.  The last thing I want to see on 
another colleague's machine is Python installations from EPD, macports, 
homebrew, etc. all mixed together on the same machine.  People have valid uses 
to be using whatever Python distribution for OSX they're using.

That said, EPD has issues with pip ever since the upgrade to require ssl. 
Instead you can just download the source tarball yourself and install it like so:

$ curl -O http://pypi.python.org/packages/source/a/astropy/astropy-0.2.1.tar.gz
$ pip install astropy-0.2.1.tar.gz

>
> Tom R says:
> ---
> By the way, for anyone migrating from EPD to other solutions, you may
> have to remove your .ipython folder first, as EPD uses a profile for
> IPython that can cause an error with other Python distributions (saw
> an example of that today). I can try and dig out more details if
> anyone is interested.
> ---
>
> Cheers
>      Wolfgang
>
> On 2013-04-23, at 2:50 PM, Desika Narayanan <dnarayanan at as.arizona.edu
> <mailto:dnarayanan at as.arizona.edu>> wrote:
>
>> Yep - exactly
>> -d
>>
>> On Tue, Apr 23, 2013 at 11:49 AM, Wolfgang Kerzendorf <wkerzendorf at gmail.com
>> <mailto:wkerzendorf at gmail.com>> wrote:
>>
>>     Are you running the enthought package by any chance?
>>
>>     Cheers
>>        Team Astropy World Police
>>     On 2013-04-23, at 2:47 PM, Desika Narayanan <dnarayanan at as.arizona.edu
>>     <mailto:dnarayanan at as.arizona.edu>> wrote:
>>
>>>     Hey Team Astropy,
>>>
>>>     I'm having some issues installing astropy from pip (where it seems like
>>>     there's some SSL certificate problem) that I'm not sure how to fix.
>>>
>>>     I'm running Mountain Lion (OS X) and python version 2.7.3:
>>>
>>>     >>> import sys
>>>     >>> print sys.version
>>>     2.7.3 |EPD 7.3-1 (32-bit)| (default, Apr 12 2012, 11:28:34)
>>>     [GCC 4.0.1 (Apple Inc. build 5493)]
>>>
>>>
>>>     When I do:
>>>
>>>     [longtrail:~] dnarayanan% pip install astropy
>>>
>>>     I get:
>>>
>>>     Downloading/unpacking astropy
>>>       Could not fetch URL https://pypi.python.org/simple/astropy/: There was
>>>     a problem confirming the ssl certificate: <urlopen error [Errno 1]
>>>     _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
>>>     message digest algorithm>
>>>       Will skip URL https://pypi.python.org/simple/astropy/ when looking for
>>>     download links for astropy
>>>       Could not fetch URL https://pypi.python.org/simple/: There was a
>>>     problem confirming the ssl certificate: <urlopen error [Errno 1]
>>>     _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
>>>     message digest algorithm>
>>>       Will skip URL https://pypi.python.org/simple/ when looking for download
>>>     links for astropy
>>>       Cannot fetch index base URL https://pypi.python.org/simple/
>>>       Could not fetch URL https://pypi.python.org/simple/astropy/: There was
>>>     a problem confirming the ssl certificate: <urlopen error [Errno 1]
>>>     _ssl.c:504: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown
>>>     message digest algorithm>
>>>       Will skip URL https://pypi.python.org/simple/astropy/ when looking for
>>>     download links for astropy
>>>       Could not find any downloads that satisfy the requirement astropy
>>>     Cleaning up...
>>>     No distributions at all found for astropy
>>>
>>>
>>>
>>>
>>>     Thanks for any help
>>>
>>>     -desika
>>>
>>>
>>>     _______________________________________________
>>>     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
> http://mail.scipy.org/mailman/listinfo/astropy
>



From eebanado at uc.cl  Wed Apr 24 03:50:43 2013
From: eebanado at uc.cl (=?ISO-8859-1?Q?Eduardo_Ba=F1ados_Torres?=)
Date: Wed, 24 Apr 2013 09:50:43 +0200
Subject: [AstroPy] ascii.read() OverflowError: Python int too large to
	convert to C long
Message-ID: <CAE_d_sDaQC1HkxL=-C_tQq_DZHs289HPYCxmh5_HivJGz5W_Bg@mail.gmail.com>

Hi all,

I am reading a text file with many columns. The first one is the obj_id
which is a long integer. When I try to open the file with ascii.read() I
get
OverflowError: Python int too large to convert to C long

while doing the same with numpy.loadtxt I don't get the error but the
integer is converted to a float (which would be fine with me)

Does anyone know how can I workaround this in astropy? I would like to work
with astropy

Thanks!

Here is a minimal self-content example:

-----------------------------
from astropy.io import ascii
from StringIO import StringIO

d = StringIO("obj_id x y \n4905757000345846002 21 72\n4905757000345846003
35 58")
#In the following line I get the error
c = ascii.read(d)

#now using numpy
import numpy as np
cn = np.loadtxt(d, skiprows=1)
print cn.T[0]
#check
print cn.T[0][0] == 4905757000345846002
#True
---------------------------------------------
-- 
Eduardo Ba?ados
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130424/75aecf2e/attachment.html>

From eebanado at uc.cl  Wed Apr 24 04:26:18 2013
From: eebanado at uc.cl (=?ISO-8859-1?Q?Eduardo_Ba=F1ados_Torres?=)
Date: Wed, 24 Apr 2013 10:26:18 +0200
Subject: [AstroPy] ascii.read() OverflowError: Python int too large to
	convert to C long
In-Reply-To: <CAE_d_sDaQC1HkxL=-C_tQq_DZHs289HPYCxmh5_HivJGz5W_Bg@mail.gmail.com>
References: <CAE_d_sDaQC1HkxL=-C_tQq_DZHs289HPYCxmh5_HivJGz5W_Bg@mail.gmail.com>
Message-ID: <CAE_d_sBXRWK6iFzcXkJZbu2VHSxeWFm75GirbSZoY3==cBPXow@mail.gmail.com>

I would like to thank Johannes Sahlmann who pointed me out the solution
(off-list I think)

For completeness, this solves the problem:

from astropy.io import ascii
from StringIO import StringIO

d = StringIO("obj_id x y \n4905757000345846002 21 72\n4905757000345846003
35 58")
converter = {'obj_id':[ascii.convert_numpy(np.int64)]}
c = ascii.read(d, converters=converter)
print c

Thanks again,


On Wed, Apr 24, 2013 at 9:50 AM, Eduardo Ba?ados Torres <eebanado at uc.cl>wrote:

> Hi all,
>
> I am reading a text file with many columns. The first one is the obj_id
> which is a long integer. When I try to open the file with ascii.read() I
> get
> OverflowError: Python int too large to convert to C long
>
> while doing the same with numpy.loadtxt I don't get the error but the
> integer is converted to a float (which would be fine with me)
>
> Does anyone know how can I workaround this in astropy? I would like to
> work with astropy
>
> Thanks!
>
> Here is a minimal self-content example:
>
> -----------------------------
> from astropy.io import ascii
> from StringIO import StringIO
>
> d = StringIO("obj_id x y \n4905757000345846002 21 72\n4905757000345846003
> 35 58")
> #In the following line I get the error
> c = ascii.read(d)
>
> #now using numpy
> import numpy as np
> cn = np.loadtxt(d, skiprows=1)
> print cn.T[0]
> #check
> print cn.T[0][0] == 4905757000345846002
> #True
> ---------------------------------------------
> --
> Eduardo Ba?ados
>



-- 
Eduardo Ba?ados
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130424/18a23f22/attachment.html>

From thomas.robitaille at gmail.com  Thu Apr 25 12:09:16 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Thu, 25 Apr 2013 17:09:16 +0100
Subject: [AstroPy] APLpy 0.9.9 released!
Message-ID: <CAGMHX_1dS4XviHSM026Y_w=5roO-0OZF23UUuHVXrLhgHXER7A@mail.gmail.com>

We are pleased to announce the release of APLpy 0.9.9! APLpy is a
Python module that makes it easy to interactively produce
publication-quality plots of astronomical images:

http://aplpy.github.io/

Since the last release, we've fixed a number of bugs reported by users
and improved stability. APLpy is fully-compatible with Python 2.6 to
3.3, and now requires Astropy (http://www.astropy.org) as its main
dependency instead of PyFITS and PyWCS. We have also added a number of
small features, including the ability to add labels to colorbars, and
the ability to save images to file objects rather than files on disks.
Note that users making use of the Montage Python wrapper and/or PyAVM
will need to update to the latest versions of these packages:

http://www.astropy.org/montage-wrapper/

http://astrofrog.github.io/pyavm/

The documentation is now hosted on ReadTheDocs:

https://aplpy.readthedocs.org/en/v0.9.9/

A full list of changes in this version can be found here:

https://raw.github.com/aplpy/aplpy/v0.9.9/CHANGES.rst

If you use pip or easy_install, you should now be able to update to 0.9.9:

pip install aplpy --upgrade

Note that if you are a Mac user, 0.9.9 will be available via MacPorts
later today (you will need to type 'sudo port selfupdate' to see it).

Please let us know if you have any issues with this release! The best
place to report any issues is via GitHub:

https://github.com/aplpy/aplpy/issues

Cheers,

The APLpy developers


From l.fogarty at physics.usyd.edu.au  Mon Apr 29 19:21:17 2013
From: l.fogarty at physics.usyd.edu.au (Lisa Fogarty)
Date: Tue, 30 Apr 2013 09:21:17 +1000
Subject: [AstroPy] Sigma clipping along an axis?
Message-ID: <CAEHmwdHctgmx0uFNctKgkK+m=3u6K8+99zyg_NxE=csohpR=3A@mail.gmail.com>

Hi All,

I would like to perform a sigma-clipped sum of several data frames (60x60
pixels each). I have put the frames into a 3D array - so if I have N frames
the array is 60x60xN. I therefore want to sigma clip along the z-axis. As
far as I can see the astropy.stats.sigma_clip function ravels the data
before performing the sigma clip (i.e. it clips in the whole array, where I
want to clip pixel-by-pixel). Is there a pythonic way I can accomplish what
I want to do?

Many thanks,
Lisa.

-- 
Dr Lisa Fogarty | Postdoctoral Research Associate, SIfA, Sydney Institute
for Astronomy
School of Physics | Faculty of Science

THE UNIVERSITY OF SYDNEY
Rm 464, Physics Building A29 | The University of Sydney | NSW | 2006
| AUSTRALIA

T +61 2 935 13112
E  l.fogarty at physics.usyd.edu.au | W
http://sydney.edu.au/science/**physics<http://sydney.edu.au/science/physics>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130430/f55aa8b5/attachment.html>

From erik.tollerud at gmail.com  Mon Apr 29 19:48:34 2013
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Mon, 29 Apr 2013 19:48:34 -0400
Subject: [AstroPy] Sigma clipping along an axis?
In-Reply-To: <CAEHmwdHctgmx0uFNctKgkK+m=3u6K8+99zyg_NxE=csohpR=3A@mail.gmail.com>
References: <CAEHmwdHctgmx0uFNctKgkK+m=3u6K8+99zyg_NxE=csohpR=3A@mail.gmail.com>
Message-ID: <CAARXUwV1Rm=mqFY6J5XX8xiFgtJrbdRaqcrUFqEB2RtiSKxoSw@mail.gmail.com>

So what do you want as the output?  If you want only the *values* that
are clipped/not clipped, you can't get an array back, because each of
the 60x60 sub-arrays will give you *different* lengths of clipped
arrays back.  So perhaps you want the mask of clipped arrays?  If so,
most straightforward is probably (unfortunately) nested for loops:


from astropy.stats import sigma_clip

frames = *your 60x60xN array*

masks = [[sigma_clip(subarrj, ...)[1]  for  subarrj in subarri] for
subarri in frames] #gmail will probably break this into multiple
line... but it's supposed to be all one line

maskarr = np.array(masks)


After that, maskarr will be a 60x60xN boolean array that is *False*
where the data was clipped, and *True* where it is valid.

There's also probably a way to adjust the astropy.stats.sigma_clip
function to do this automatically and in a more numpy-optimized way.
Feel free to add this as an issue for
astropy (https://github.com/astropy/astropy/issues).


On Mon, Apr 29, 2013 at 7:21 PM, Lisa Fogarty
<l.fogarty at physics.usyd.edu.au> wrote:
> Hi All,
>
> I would like to perform a sigma-clipped sum of several data frames (60x60
> pixels each). I have put the frames into a 3D array - so if I have N frames
> the array is 60x60xN. I therefore want to sigma clip along the z-axis. As
> far as I can see the astropy.stats.sigma_clip function ravels the data
> before performing the sigma clip (i.e. it clips in the whole array, where I
> want to clip pixel-by-pixel). Is there a pythonic way I can accomplish what
> I want to do?
>
> Many thanks,
> Lisa.
>
> --
> Dr Lisa Fogarty | Postdoctoral Research Associate, SIfA, Sydney Institute
> for Astronomy
> School of Physics | Faculty of Science
>
> THE UNIVERSITY OF SYDNEY
> Rm 464, Physics Building A29 | The University of Sydney | NSW | 2006
> | AUSTRALIA
>
> T +61 2 935 13112
> E  l.fogarty at physics.usyd.edu.au | W  http://sydney.edu.au/science/physics
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



--
Erik


From l.fogarty at physics.usyd.edu.au  Mon Apr 29 20:30:41 2013
From: l.fogarty at physics.usyd.edu.au (Lisa Fogarty)
Date: Tue, 30 Apr 2013 10:30:41 +1000
Subject: [AstroPy] Sigma clipping along an axis?
In-Reply-To: <CAARXUwV1Rm=mqFY6J5XX8xiFgtJrbdRaqcrUFqEB2RtiSKxoSw@mail.gmail.com>
References: <CAEHmwdHctgmx0uFNctKgkK+m=3u6K8+99zyg_NxE=csohpR=3A@mail.gmail.com>
	<CAARXUwV1Rm=mqFY6J5XX8xiFgtJrbdRaqcrUFqEB2RtiSKxoSw@mail.gmail.com>
Message-ID: <CAEHmwdF+AeQOr7tR0oxvUJ_aHOBCGL+EjzuL9FGH12wQH_t6gg@mail.gmail.com>

Hi Erik,

Yes, the Boolean array with False for clipped data is exactly what I
wanted. This works well, thank-you! I like the feature in sigma_clip of
being able to define the centre function and variance function - it makes
NaN handling easy which I was previously worried about.

Thank-you again for your answer! I will submit a feature request as you
suggest.

Yours,
Lisa.




On Tue, Apr 30, 2013 at 9:48 AM, Erik Tollerud <erik.tollerud at gmail.com>wrote:

> So what do you want as the output?  If you want only the *values* that
> are clipped/not clipped, you can't get an array back, because each of
> the 60x60 sub-arrays will give you *different* lengths of clipped
> arrays back.  So perhaps you want the mask of clipped arrays?  If so,
> most straightforward is probably (unfortunately) nested for loops:
>
>
> from astropy.stats import sigma_clip
>
> frames = *your 60x60xN array*
>
> masks = [[sigma_clip(subarrj, ...)[1]  for  subarrj in subarri] for
> subarri in frames] #gmail will probably break this into multiple
> line... but it's supposed to be all one line
>
> maskarr = np.array(masks)
>
>
> After that, maskarr will be a 60x60xN boolean array that is *False*
> where the data was clipped, and *True* where it is valid.
>
> There's also probably a way to adjust the astropy.stats.sigma_clip
> function to do this automatically and in a more numpy-optimized way.
> Feel free to add this as an issue for
> astropy (https://github.com/astropy/astropy/issues).
>
>
> On Mon, Apr 29, 2013 at 7:21 PM, Lisa Fogarty
> <l.fogarty at physics.usyd.edu.au> wrote:
> > Hi All,
> >
> > I would like to perform a sigma-clipped sum of several data frames (60x60
> > pixels each). I have put the frames into a 3D array - so if I have N
> frames
> > the array is 60x60xN. I therefore want to sigma clip along the z-axis. As
> > far as I can see the astropy.stats.sigma_clip function ravels the data
> > before performing the sigma clip (i.e. it clips in the whole array,
> where I
> > want to clip pixel-by-pixel). Is there a pythonic way I can accomplish
> what
> > I want to do?
> >
> > Many thanks,
> > Lisa.
> >
> > --
> > Dr Lisa Fogarty | Postdoctoral Research Associate, SIfA, Sydney Institute
> > for Astronomy
> > School of Physics | Faculty of Science
> >
> > THE UNIVERSITY OF SYDNEY
> > Rm 464, Physics Building A29 | The University of Sydney | NSW | 2006
> > | AUSTRALIA
> >
> > T +61 2 935 13112
> > E  l.fogarty at physics.usyd.edu.au | W
> http://sydney.edu.au/science/physics
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
> >
>
>
>
> --
> Erik
>



-- 
Dr Lisa Fogarty | Postdoctoral Research Associate, SIfA, Sydney Institute
for Astronomy
School of Physics | Faculty of Science

THE UNIVERSITY OF SYDNEY
Rm 464, Physics Building A29 | The University of Sydney | NSW | 2006
| AUSTRALIA

T +61 2 935 13112
E  l.fogarty at physics.usyd.edu.au | W
http://sydney.edu.au/science/**physics<http://sydney.edu.au/science/physics>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130430/3cacf866/attachment.html>

From ejensen1 at swarthmore.edu  Tue Apr 30 10:13:57 2013
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Tue, 30 Apr 2013 10:13:57 -0400
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
Message-ID: <201741AA-D7AE-4D07-9BBC-A033D789F54C@swarthmore.edu>

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

 

From mrdavis at stsci.edu  Tue Apr 30 10:20:09 2013
From: mrdavis at stsci.edu (Matt Davis)
Date: Tue, 30 Apr 2013 14:20:09 +0000
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <201741AA-D7AE-4D07-9BBC-A033D789F54C@swarthmore.edu>
References: <201741AA-D7AE-4D07-9BBC-A033D789F54C@swarthmore.edu>
Message-ID: <134BF784-CA16-40AF-933E-EF995475655E@stsci.edu>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130430/43b0f4e7/attachment.html>

From Paul.A.Ries at jpl.nasa.gov  Tue Apr 30 11:21:35 2013
From: Paul.A.Ries at jpl.nasa.gov (Ries, Paul A (3265-Affiliate))
Date: Tue, 30 Apr 2013 15:21:35 +0000
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <134BF784-CA16-40AF-933E-EF995475655E@stsci.edu>
References: <201741AA-D7AE-4D07-9BBC-A033D789F54C@swarthmore.edu>
	<134BF784-CA16-40AF-933E-EF995475655E@stsci.edu>
Message-ID: <4659B9E7-EB63-4E65-A1DC-266B3865F1D2@jpl.nasa.gov>

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

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

From thomas.robitaille at gmail.com  Tue Apr 30 11:25:32 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Tue, 30 Apr 2013 17:25:32 +0200
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <134BF784-CA16-40AF-933E-EF995475655E@stsci.edu>
References: <201741AA-D7AE-4D07-9BBC-A033D789F54C@swarthmore.edu>
	<134BF784-CA16-40AF-933E-EF995475655E@stsci.edu>
Message-ID: <CAGMHX_3ymPRRgmu4o-MzBo7C--VnFdQx6FwA5gjvgcSq4VWJDQ@mail.gmail.com>

Even though I wrote the MacPorts Python guide, if you want to get set
up quickly, then I'm going to +1 Anaconda - it's certainly the fastest
and easiest way to get set up, and you'll automatically get Astropy
(which is included by default), and you won't have to worry about root
vs non-root issues since Anaconda is installed into your home
directory.

Cheers,
Tom

On 30 April 2013 16:20, Matt Davis <mrdavis at stsci.edu> 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
>


From lsinger at caltech.edu  Tue Apr 30 11:29:20 2013
From: lsinger at caltech.edu (Leo Singer)
Date: Tue, 30 Apr 2013 10:29:20 -0500
Subject: [AstroPy] Enthought Canopy vs. another distribution for Mac?
In-Reply-To: <mailman.47.1367334996.1039.astropy@scipy.org>
References: <mailman.47.1367334996.1039.astropy@scipy.org>
Message-ID: <B51FD4E6-4E78-4333-891A-C0E0B0938159@caltech.edu>

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

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

From duncan.macleod at ligo.org  Tue Apr 30 13:02:13 2013
From: duncan.macleod at ligo.org (Duncan Macleod)
Date: Tue, 30 Apr 2013 18:02:13 +0100
Subject: [AstroPy] Are there astropy packages for redhat/debian linux?
Message-ID: <etPan.517ff915.2d1d5ae9.c9@v1266-0a9bc7d3.wifi.cf.ac.uk>

Hi all,

I'm wondering if astropy has been packaged for linux, and if I can install it using the apt or yum package managers? If so, I'll have an easier time convincing my computing cluster admin to install it (probably).


Duncan
--
Duncan Macleod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130430/77ac56a2/attachment.html>

From astropy at liska.ath.cx  Tue Apr 30 13:10:37 2013
From: astropy at liska.ath.cx (=?utf-8?Q?Ol=D0=B5?= Streicher)
Date: Tue, 30 Apr 2013 19:10:37 +0200
Subject: [AstroPy] Are there astropy packages for redhat/debian linux?
References: <etPan.517ff915.2d1d5ae9.c9@v1266-0a9bc7d3.wifi.cf.ac.uk>
Message-ID: <871u9sc5bm.fsf@news.ole.ath.cx>

Duncan Macleod <duncan.macleod at ligo.org> writes:
> I'm wondering if astropy has been packaged for linux, and if I can install it
> using the apt or yum package managers? If so, I'll have an easier time
> convincing my computing cluster admin to install it (probably).

Astropy is not part of the current Debian and Ubuntu releases, and it
also will not be in the upcoming Debian Wheezy release.

However, I just uploaded 0.2.1 to Debian unstable, and therefore it will
be part of the next (13.10) Ubuntu release. For Ubuntu, you can also
download it from my personal repository at
http://ppa.launchpad.net/olebole/astro-raring/ubuntu.

Best

Ole