pyds9 community development

(from @ericmandel) To continue this conversation on the wiki, I append the comments from @cdeil from issue 2 :

@ericmandel Thanks for all the explanations and this effort to improve the Python-DS9 interop.

@ericmandel @leejoon and @timstaley and anyone else interested: How about scheduling a Google hangout in the near future to have a chat?

Before that it would be nice to summarise what pyds9, pysao and pyds9_ex and other high-level interfaces users have created do exactly and to list questions and suggestions how to proceed. @ericmandel Can you please activate the wiki pages for pyds9 on github ... this seems like the best place to gather such info.

In the meantime I'll put some info here (please comment if anything is wrong):

pyds9 is the official interface from the ds9 devs (contact: @ericmandel), has a GPL license and consists of about 700 lines of Python code (ds9.py and a 200 line Python ctypes interface xpa.py) to XPA. It needs some work (docs, tests, Python 3) pyds9_ex is a wrapper class and a few wrapper functions around pyds9 to make usage easier (contact: @timstaley). It consists of about 100 lines of Python code (ds9_ex). pysao is an alternative to pyds9 implemented and maintained by @leejoon. It does not build on pyds9, it's a completely independent alternative. It uses a 200 line Cython interface xpa.pyx and has about 1600 lines of Python code here. Any other relevant codes? Which interface does CIAO Sherpa use? Here's some questions I have about the low-level part:

• Is there any point in having both pyds9 and pysao?
• Is there anything fundamental that one can do and the other can't? Or is the ctypes or Cython interface more efficient? If not a ctypes interface is preferable because it is pure-Python, i.e. simpler to install for users?
• If both are equivalent I think it would be better for users to remove one. Otherwise 1/2 of the users use and have learned the API of pyds9 and the other of pysao, which is bad for sharing knowledge and scripts with colleagues. But which one to pick as the basis and what about supporting existing users of the other?

About the high-level part we can be discussed later, just one comment:

• If we can agree on an API it would be better to include it in one package with the low-level interface. Making users find and install another package like pyds9_ex for just a few 100 lines of Python code is bad.
• If the high-level classes and functions are not general enough to warrant inclusion with the low-level package, maybe a list of user-contributed extensions like the IPython extensions index would be a good solution with very popular extensions migrating into the main package over time. Sorry for the long text ... I'm just a user and will shut up now ... time for the devs (@ericmandel and @leejoon) to say what they think should be done.

(from @eteq) I think @cdeil's question about pyds9 vs. pysao is of particular interest - if the answer is that they can share all the same "low-level" functionality, then they should - it's hard for the broader community, otherwise. (I'm coming at this from the perspective of astropy, which is based on the idea that a shared community-developed core helps everyone.)

(from @ericmandel, this also is on the issues page, not sure which is better for conversation!) I agree that the underlying part of pysao overlaps the function of pyds9 and only one is needed. I am not a python expert, so I cannot comment on whether ctypes or Cython is preferable. I will say that we are willing to continue support for pyds9 as part of the ds9 project, but we are amenable if the community wants to move to pysao instead -- but we probably will be less involved with its direct support.

Regarding high-level routines: my assumption has been that there will be many flavors and it will be hard to decide which to make "official". This is the reason we are hesitant to add high-level routines directly to the core pyds9 module. So an extension index could be the right way to go.