Hello,<div><br></div><div>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. </div><div><br></div><div>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!</div>
<div><br></div><div>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".</div>
<div><br></div><div>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.</div>
<div><br></div><div>Getting back to installing Python packages.</div><div><br></div><div>+ I use the Linux package manager to install all "heavy duty" non-Python and Python packages. </div><div><br></div><div> These include C/C++ libraries such as HDF5, QT4, and Python packages such as wxPython, PyQt, etc., I </div>
<div> make it a point to install the "dev" or "devel" packages along with the main package. So, these will be </div><div> shared by all Python interpreters.</div><div><br></div><div>+ I set PYTHONPATH="".</div>
<div><br></div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>+ I use <a href="http://pypi.python.org/pypi/virtualenv">virtualenv</a> and <a href="http://pypi.python.org/pypi/virtualenvwrapper">virtualenvwrapper</a> for managing all my Python installations.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div> I won't go into how to install and setup these; it is given in the websites for these packages and is very easy.</div>
<div><meta http-equiv="content-type" content="text/html; charset=utf-8"> These tools are widely used by the web development community. I haven't come across any serious </div><div> criticisms of these tools from this community.</div>
<div><br></div><div> The latter is built on top of the former and my interactions are limited to the latter. This tool allows one to </div><div> select the Python interpreter to use, gives the option to use or not use the root "site-packages" </div>
<div> directory of the chosen interpreter, and completely separates one Python interpreter from </div><div> another, except for the "~/.local" path (?).</div><div><br></div><div> If I want to create an environment with the default Python then I issue a command like:</div>
<div><br></div><div> $ mkvirtualenv --no-site-packages --distribute name_of_env</div><div><br></div><div> The above command will create a virtual environment that uses the default Python, that excludes the </div><div> contents of the default Python's "site-packages" directory, and will use the distribute package for handling </div>
<div> installations. It also installs "pip". I usually do not use the "--no-site-packages" options, since till now I </div><div> haven't managed to manually install the wxPython/wxWidgets package! I rely on the version supplied with </div>
<div> Ubuntu, which of-course gets installed in the root "site-packages" directory.</div><div><br></div><div> This doesn't need root privileges. The virtual environment will be created in the location specified by </div>
<div> environment variables that are read by virtualenv and virtualenvwrapper.</div><div><br></div><div> If I want to have an environment that uses another Python interpreter then I would download the Python </div><div>
interpreter and install it in some folder, say "~/bin/python2.7", and then use the option "--python" to point to </div><div> the binary executable inside the "~/bin/python2.7/bin" directory. Also, one can create multiple environments </div>
<div> that use the same interpreter. I think this can be done for EPD too: just specify path to EPD Python </div><div> executable. This would be another situation, where I would not use the "--no-site-packages" options; if I were </div>
<div> using EPD I would like to use all the packages that come with it.</div><div><br></div><div> When I want to work in a given environment, I type:</div><div><br></div><div> $ workon name_of_env</div><div><br></div><div>
The "name_of_env" string will be displayed in the command line prompt and so it is easy to see which </div><div> environment one is working in. All Python related commands will now use the Python that corresponds to </div>
<div> this environment.</div><div><br></div><div> To leave the environment I type:</div><div><br></div><div> $ deactivate</div><div><br></div><div> The "name_of_env" string will be removed from the prompt, and the default Python will be used when </div>
<div> needed. </div><div><br></div><div> If I want to delete an environment I use, say because I want to start fresh:</div><div><br></div><div> $ rmvirtualenv name_of_env</div><div><br></div><div> There are command line completions available for these commands. These are the only commands that I </div>
<div> have used so far, and they have served me well.</div><div><br></div><div>+ Installing packages</div><div><br></div><div> I download the source code for the package, and run "python setup.py install", while inside an environment. </div>
<div> This doesn't need root privileges, since the package will be installed somewhere in the user's home </div><div> directory, as specified while setting up virtualenv and virtualenvwrapper.</div><div><br></div>
<div> I do not delete the source code. When I want to install the same in another environment, I switch to that </div><div> environment and then simply repeat the process. Just to make sure that everything gets compiled again, I </div>
<div> delete the "build" directory before running setup.py.</div><div> </div><div> For packages that work with "pip" or "easy_install", I run the appropriate command while inside the </div>
<div> environment. Anything that I do inside an environment, will affect only that environment. In fact, virtualenv </div><div> will refuse to install packages that try to modify items outside the current environment(?).</div>
<div><br></div><div> I try not to use the "--user" option with setup.py and pip. If I need to use the same package with another </div><div> Python, I simply install it again, after switching to the concerned environment.</div>
<div><br></div><div>+ These steps have, till now, worked very well for me. The only complication that I can anticipate is when I will </div><div> need a version of the "heavy duty" C/C++ and Python packages, that is not supplied by the linux </div>
<div> distribution.</div><div><br></div><div>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.</div>
<div><br></div><div>Even though this is a long description and sounds complicated, in practice it is very easy. Hope this doesn't add to the confusion! </div><div><br></div><div>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?</div>
<div><br></div><div>Thanks,</div><div>Prasanth</div><div><br><div class="gmail_quote">On Sat, May 28, 2011 at 12:16 AM, Mark Sienkiewicz <span dir="ltr"><<a href="mailto:sienkiew@stsci.edu">sienkiew@stsci.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Tom Aldcroft wrote:<br>
> As people have noted, getting SciSoft and EPD to play together and<br>
> allowing easy switching between environments could be tricky.<br>
<br>
<br>
</div>There is an easy answer: Don't switch between environments.<br>
<br>
- start a terminal window<br>
- select an environment<br>
- work in that environment<br>
- close that terminal window<br>
<br>
For your default login configuration, do not select either environment.<br>
Once you select an environment, just live with the constraint that you<br>
can't select the other one in the same terminal window. Since you can<br>
have arbitrarily many terminal windows, it should not be that much of a<br>
hardship.<br>
<font color="#888888"><br>
Mark<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
AstroPy mailing list<br>
<a href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/astropy" target="_blank">http://mail.scipy.org/mailman/listinfo/astropy</a><br>
</div></div></blockquote></div><br></div>