[AstroPy] Practical Python for Astronomers web tutorial

Sat May 28 05:31:48 EDT 2011

Hello,

I thought I will share the methods I use while dealing with Python packages.
I use Linux though most, but not all, of this should be relevant for Mac and
Windows users.

Before I do that, I have a suggestion specifically regarding the REU program
mentioned in a previous email: after teaching students the basics of Python,
shouldn't they be exposed to the manual installation process? We don't want
new users to start with installing packages, but say after 1 or 2 week of
playing with Python and astronomy specific packages, perhaps they should try
installing packages on their own, without relying on, say EPD. At some point
we do need people to be able to do this. They may get frustrated early on,
but it is better to get frustrated, and over come it, during summer than
during the academic year!

I would also like to suggest that, students who haven't programmed before
should be asked to go through some basic Python material, such as the
official tutorial or an intensive 1 or 2 day "boot camp" like class, before
taking them through "python4astronomers".

With regard to the same email, installing IRAF is now pretty easy, at-least
on linux machines. The latest version can do automatic installation, and
dependency handling, of many packages such as STSDAS. So  there is no need
for using Scisoft just for getting IRAF.

Getting back to installing Python packages.

+ I use the Linux package manager to install all "heavy duty" non-Python and
Python packages.

   These include C/C++ libraries such as HDF5, QT4, and Python packages such
as wxPython, PyQt, etc., I
   make it a point to install the "dev" or   "devel" packages along with the
main package. So, these will be
   shared by all Python interpreters.

+ I set PYTHONPATH="".

+ I use virtualenv <http://pypi.python.org/pypi/virtualenv> and
virtualenvwrapper <http://pypi.python.org/pypi/virtualenvwrapper> for
managing all my Python installations.

  I won't go into how to install and setup these; it is given in the
websites for these packages and is very easy.
  These tools are widely used by the web development community. I haven't
come across any serious
  criticisms of these tools from this community.

  The latter is built on top of the former and my interactions are limited
to the latter. This tool allows one to
  select the Python interpreter to use, gives the option to use or not use
the root "site-packages"
  directory  of the chosen interpreter, and completely separates one Python
interpreter from
  another, except for the "~/.local" path (?).

  If I want to create an environment with the default Python then I issue a
command like:

  $ mkvirtualenv --no-site-packages --distribute name_of_env

  The above command will create a virtual environment that uses the default
Python, that excludes the
  contents of the default Python's "site-packages" directory, and will use
the distribute package for handling
  installations.  It also installs "pip". I usually do not use the
"--no-site-packages" options, since till now I
  haven't managed to  manually install the wxPython/wxWidgets package! I
rely on the version supplied with
  Ubuntu, which of-course gets installed in the root "site-packages"
directory.

  This doesn't need root privileges. The virtual environment will be created
in the location specified by
  environment variables that are read by virtualenv and virtualenvwrapper.

  If I want to have an environment that uses another Python interpreter then
I would download the Python
  interpreter and install it in some folder, say "~/bin/python2.7", and then
use the option "--python" to point to
  the binary executable inside the "~/bin/python2.7/bin" directory. Also,
one can create multiple environments
  that use the same interpreter. I think this can be done for EPD too: just
specify path to EPD Python
  executable. This would be another situation, where I would not use the
"--no-site-packages" options; if I were
  using EPD I would like to use all the packages that come with it.

  When I want to work in a given environment, I type:

  $ workon name_of_env

  The "name_of_env" string will be displayed in the command line prompt and
so it is easy to see which
  environment one is working in. All Python related commands will now use
the Python that corresponds to
  this environment.

  To leave the environment I type:

  $ deactivate

  The "name_of_env" string will be removed from the prompt, and the default
Python will be used when
  needed.

  If I want to delete an environment I use, say because I want to start
fresh:

  $ rmvirtualenv name_of_env

  There are command line completions available for these commands. These are
the only commands that I
  have used so far, and they have served me well.

+  Installing packages

   I download the source code for the package, and run "python setup.py
install", while inside an environment.
   This doesn't need root privileges, since the package will be installed
somewhere in the user's home
   directory, as specified while setting up virtualenv and
virtualenvwrapper.

   I do not delete the source code. When I want to install the same in
another environment, I switch to that
   environment and then simply repeat the process. Just to make sure that
everything gets compiled again, I
   delete the "build" directory before running setup.py.

   For packages that work with "pip" or "easy_install", I run the
appropriate command while inside the
   environment. Anything that I do inside an environment, will affect only
that environment. In fact, virtualenv
   will refuse to install packages that try to modify items outside the
current environment(?).

   I try not to use the "--user" option with setup.py and pip. If I need to
use the same package with another
   Python, I simply install it again, after switching to the concerned
environment.

+ These steps have, till now, worked very well for me. The only complication
that I can anticipate is when I will
   need a version of the "heavy duty" C/C++ and Python packages, that is not
supplied by the linux
   distribution.

In short, the very first command that I type in my terminal, when starting
to work with Python, is "workon some_name". Then I just stay in that
environment. Only on few occasions do I need to switch to a different
environment, say when trying out a new version of a package, or testing code
using a different version of Python.

Even though this is a long description and sounds complicated, in practice
it is very easy. Hope this doesn't add to the confusion!

I would really like to hear from others who have used these tools. Perhaps
someone has run into problems that I haven't? Does this work on Mac OS X and
Windows?

Thanks,
Prasanth

On Sat, May 28, 2011 at 12:16 AM, Mark Sienkiewicz <sienkiew at stsci.edu>wrote:

> Tom Aldcroft wrote:
> > As people have noted, getting SciSoft and EPD to play together and
> > allowing easy switching between environments could be tricky.
>
>
> There is an easy answer:  Don't switch between environments.
>
> - start a terminal window
> - select an environment
> - work in that environment
> - close that terminal window
>
> For your default login configuration, do not select either environment.
> Once you select an environment, just live with the constraint that you
> can't select the other one in the same terminal window.  Since you can
> have arbitrarily many terminal windows, it should not be that much of a
> hardship.
>
> Mark
>
> _______________________________________________
> 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/20110528/0d1ce683/attachment.html>