[AstroPy] Putting astronomy packages on PyPI
thomas.robitaille at gmail.com
Wed May 4 08:15:57 EDT 2011
I also agree with putting packages on PyPI, and the suggestion of using pip over easy_install.
I just wanted to add one comment about PyPI for anyone who is still not convinced - you don't actually have to put a tar file on PyPI if you don't want, and you definitely don't have to provide binary distributions. Take a look at ATpy for example: http://pypi.python.org/pypi/ATpy - all this is is some meta-data pointing to the source tar file hosted on GitHub. This is the bare minimum, but still allows people to use 'pip install atpy'.
It's also possible to set up your environment so that all you do is type 'python setup.py register' and the latest version of your package will be added to PyPI:
Finally one thing that we should look at closely is pip bundles:
Apparently this is not stable at this stage, but the idea would be to be able to distribute many packages together, which should clearly be of interest to us.
On Wednesday, May 4, 2011 at 5:03 AM, Luigi Paioro wrote:
> I agree with you. A common packaging system for the astronomical
> software would be desirable in general, but, at least for the Python
> based software, we already have PyPI + pip, and I think there should be
> a shared effort to promote such system. This is one of the reasons that
> has led me to put SAMPy available on PyPI.
> Take also into account that, in principle, distutils/setuptools packages
> can be extended in order provide additional features specific for the
> astronomical community, if needed. For instance, within the context of
> the OPTICON funded FASE project, I have already coded an extension which
> allows to compile C code as libraries and/or executables (along with
> extension modules, of course)... so far it is not as flexible as `make`
> but, at least on Linux, it works... I can imaging a future
> implementation supporting even other languages (Java, FORTRAN, IDL,
> ...). This futuristic vision, if realized, would be a great revolution
> in the astronomical software, but everything starts from little efforts
> like just putting packages on PyPI, as Erik and Tom are sustaining.
> Best regards,
> Il 05/04/11 01:41, Erik Tollerud ha scritto:
> > I definitely agree that putting packages on PyPI is a desirable thing,
> > and it really is very easy to do. Having all these packages on PyPI
> > would also make it possible to write automated installer tools to
> > install everything in one go (e.g. astpys-setup in astropysics works
> > because the PyPI data is easy to access automatically).
> > One tip that I think may be of particular use to packages that require
> > compilation: we should stop using "easy_install" and switch to "pip
> > install".
> > Setuptools and easy_install are not being developed anymore, and are
> > python 3.0 incompatible. The replacement for setuptools is distribute
> > (http://pypi.python.org/pypi/distribute), which emulates all of the
> > setuptools functionality and is actively being developed (although in
> > the future it is going to be replaced by a standard library tool).
> > The replacement for easy_install is pip
> > (http://pypi.python.org/pypi/pip/1.0.1). pip is different from
> > easy_install in that it installs from source where possible, which
> > makes it much more robust in most settings - my experience is that it
> > usually just works, unlike easy_install (at least for more complicated
> > packages). Pip is also much cleaner about where it puts packages, and
> > doesn't cause all the strange path problems you sometimes see when you
> > install multiple versions of something in easy_install. Pip also
> > includes an "uninstall" option, which is very useful for certain
> > situations.
> > By the way, pyfits is on PyPI
> > (http://pypi.python.org/pypi/pyfits/2.4.0) - "pip install pyfits"
> > works for me (both in OS X and Linux).
> > On Tue, May 3, 2011 at 6:34 AM, Tom Aldcroft
> > <aldcroft at head.cfa.harvard.edu> wrote:
> > > I see there has been some discussion previously on the idea of putting
> > > packages on PyPI (in particular for vo-0.6). There did not seem to
> > > have been a resolution so I want to ask once more why it is not
> > > possible or desirable to do so.
> > >
> > > As background, over the last two months my colleagues and I at CfA
> > > have been running a series of workshops on Practical Python for
> > > Astronomers. The first and most difficult workshop was building a
> > > usable Python installation on individual laptops supporting Mac
> > > (mostly), linux, and Windows. Once we got the base installation done
> > > with Python, NumPy, SciPy and matplotlib then there were a bunch of
> > > other packages that we use during the workshops. The instructions for
> > > installing these were:
> > >
> > > easy_install asciitable
> > > easy_install http://www.stsci.edu/resources/software_hardware/pyfits/pyfits-2.4.0.tar.gz
> > > easy_install pywcs
> > > easy_install atpy
> > > easy_install aplpy
> > > easy_install http://stsdas.stsci.edu/astrolib/vo-0.6.tar.gz
> > > easy_install http://stsdas.stsci.edu/astrolib/coords-0.37.tar.gz
> > > easy_install pyparsing
> > > easy_install pyregion
> > >
> > > For the most part this worked quite well across all the platforms. So
> > > why can't pyfits, vo, and coords be there on PyPI to supply the
> > > download URL to easy_install in a uniform and non-version-dependent
> > > way? (The fact that I'm singling out those three should be taken as a
> > > compliment that they are useful and worth the bother). Of course you
> > > cannot guarantee that this will *always* build properly, but it's
> > > certainly worth an initial try the "easy" way.
> > >
> > > If package authors could make their source distribution available via
> > > PyPI would be a nice step toward making Python easier to adopt for
> > > astronomers. Again I understand there can be complications and
> > > ensuring perfection is impossible, but sometimes better is the enemy
> > > of good.
> AstroPy mailing list
> AstroPy at scipy.org
More information about the AstroPy