Tag Archives: GUI

Enthought Tool Suite Release 4.4 (Traits, Chaco, and more)

Authors: The ETS Developers

We’re happy to announce the release of multiple major projects, including:

  • Traits 4.4.0
  • Chaco 4.4.1
  • TraitsUI 4.4.0
  • Envisage 4.4.0
  • Pyface 4.4.0
  • Codetools 4.2.0
  • ETS 4.4.1

These packages form the core of the Enthought Tool Suite (ETS, http://code.enthought.com/projects), a collection of free, open-source components developed by Enthought and our partners to construct custom scientific applications. ETS includes a wide variety of components, including:

  • an extensible application framework (Envisage)

  • application building blocks (Traits, TraitsUI, Enaml, Pyface, Codetools)

  • 2-D and 3-D graphics libraries (Chaco, Mayavi, Enable)

  • scientific and math libraries (Scimath)

  • developer tools (Apptools)

You can install any of the packages using Canopy‘s package manager, using the Canopy or EPD ‘enpkg \’ command, from PyPI (using pip or easy_install),  or by building them from source code on github. For more details, see the ETS intallation page.

Contributors

==================

This set of releases was an 8-month effort of Enthought developers along with:

  • Yves Delley
  • Pieter Aarnoutse
  • Jordan Ilott
  • Matthieu Dartiailh
  • Ian Delaney
  • Gregor Thalhammer

Many thanks to them!

General release notes

==================

  1. The major new feature in this Traits release is a new adaptation mechanism in the “traits.adaptation“ package.  The new mechanism is intended to replace the older traits.protocols package.  Code written against “traits.protocols“ will continue to work, although the “traits.protocols“ API has been deprecated, and a warning will be logged on first use of “traits.protocols“.  See the ‘Advanced Topics’ section of the user manual for more details.

  2. These new releases of TraitsUI, Envisage, Pyface and Codetools include an update to this new adaptation mechanism.

  3. All ETS projects are now on TravisCI, making it easier to contribute to them.

  4. As of this release, the only Python versions that are actively supported are 2.6 and 2.7. As we are moving to future-proof ETS over the coming months, more code that supported Python 2.5 will be removed.

  5. We will retire chaco-users@enthought.com since it is lightly used and are now recommending all users of Chaco to send questions, requests and comments to enthought-dev@enthought.com or to StackOverflow (tag “enthought” and possibly “chaco”).

More details about the release of each project are given below. Please see the CHANGES.txt file inside each project for full details of the changes.

Happy coding!

The ETS developers

Traits 4.4.0 release notes

=====================

The Traits library enhances Python by adding optional type-checking and an event notification system, making it an ideal platform for writing data-driven applications.  It forms the foundation of the Enthought Tool Suite.

In addition to the above-mentioned rework of the adaptation mechanism, the release also includes improved support for using Cython with `HasTraits` classes, some new helper utilities for writing unit tests for Traits events, and a variety of bug fixes, stability enhancements, and internal code improvements.

Chaco 4.4.0 release notes

=====================

Chaco is a Python package for building efficient, interactive and custom 2-D plots and visualizations. While Chaco generates attractive static plots, it works particularly well for interactive data visualization and exploration.

This release introduces many improvements and bug fixes, including fixes to the generation of image files from plots, improvements to the ArrayPlotData to change multiple arrays at a time, and improvements to multiple elements of the plots such as tick labels and text overlays.

TraitsUI 4.4.0 release notes

======================

The TraitsUI project contains a toolkit-independent GUI abstraction layer, which is used to support the “visualization” features of the Traits package. TraitsUI allows developers to write against the TraitsUI API (views, items, editors, etc.), and let TraitsUI and the selected toolkit and back-end take care of the details of displaying them.

In addition to the above-mentioned update to the new Traits 4.4.0 adaptation mechanism, there have also been a number of improvements to drag and drop support for the Qt backend and some modernization of the use of WxPython to support Wx 2.9.  This release also includes a number of bug-fixes and minor functionality enhancements.

Envisage 4.4.0 release notes

=======================

Envisage is a Python-based framework for building extensible applications, providing a standard mechanism for features to be added to an

application, whether by the original developer or by someone else.

In addition to the above-mentioned update to the new Traits 4.4.0 adaptation mechanism, this release also adds a new method to retrieve a service that is required by the application and provides documentation and test updates.

Pyface 4.4.0 release notes

======================

The pyface project provides a toolkit-independent library of Traits-aware widgets and GUI components, which are used to support the “visualization” features of Traits.

The biggest change in this release is support for the new adaptation mechanism in Traits 4.4.0. This release also includes Tasks support for Enaml 0.8 and a number of other minor changes, improvements and bug-fixes.

Codetools release notes

====================

The codetools project includes packages that simplify meta-programming and help the programmer separate data from code in Python. This library provides classes for performing dependency-analysis on blocks of Python code, and Traits-enhanced execution contexts that can be used as execution namespaces.

In addition to the above-mentioned update to the new Traits 4.4.0 adaptation mechanism, this release also includes a number of modernizations of the code base, including the consistent use of absolute imports, and a new execution manager for deferring events from Contexts.

Installing and Managing a Central Python Install with Enthought Canopy v1.1

Author: Jason McCampbell

In the last post we talked about virtual environments and how we have back-ported venv from Python 3 and extended it in Canopy 1.1. This post will now walk through how we use virtual environments to provide new options to organizations and workgroups who want to install Canopy on a multi-user network and how Canopy provides a flexible Python environment on large compute clusters without sacrificing performance.

Multi-user Network Installs

In a standard, single-user installation, Canopy creates two virtual environments, System and User. System is used for running the GUI itself and User is the main Python environment for running user code. The package set in User is completely under the user’s control (ie, won’t break the GUI).

With the 1.1 release, Canopy supports the creation of shared versions of the System and User virtual environments. These virtual environments, referred to as Common System and Common User, can be centrally managed, providing an easy means of managing a consistent set of package versions and dramatically reducing disk usage by having shared copies of the packages. Each individual user’s System and User virtual environment are layered on top of the common installs as shown below.

Canopy venv layout

In this case, Canopy Core and the two virtual environments “Common System” and “Common User” are installed in a central networked disk. Typically, all of the standard packages would be installed in “Common User”, making them available to all users. When each user first starts Canopy, the per-user virtual environments “User’s System” and “User’s User” are automatically created. Users have the freedom to install new packages and alternate package versions in their own virtual environments while still benefitting from the centrally managed package set.

To set up this structure, after installing Canopy, an administrator first runs Canopy and creates the System (“Common System”) and User (“Common User”) virtual environment in the desired location as one would in a single-user environment. Changes to the package set in User can be made by this administrative user. To make these environments available to all users, the following command is run, again as the administrative user:

canopy_cli –common-install

This writes a file named ‘location.cfg’ to Canopy Core. Now whenever a user starts Canopy, the per-user environments will be layered on top of the common environments.

The initial setup of the virtual environments, by default, uses the Canopy GUI, which is not always available or desired. To address these cases, Canopy now supports a new switch “–no-gui-setup’. See the Canopy Users Guide for more details.

Cluster Installs

Large compute clusters are an interesting special case of the multi-user network because a large number of nodes may be requiring the same resources at the same time. Starting a 1000-node job where a large number of files are required from a networked disk can increase startup time substantially, wasting precious time on an expensive cluster. Ideally, most or all of the files will be local to each node.

We can use a modified version of the multi-user setup above to address this. After installing Canopy on each node, we want to create the System and User virtual environments with all of the standard packages installed. Running the GUI to install to 1000+ machines is … inefficient… so we will use the non-GUI setup option (assuming Canopy is installed in /usr/local/Canopy on each machine):

ssh node1 /usr/local/Canopy/bin/canopy_cli –no-gui-setup –install-dir /usr/local/Canopy –common-install

Running this command once for each node in the cluster results in the virtual environments being installed to /usr/local/Canopy/Canopy_64bit on each machine. Large packages such as NumPy and SciPy can now be loaded from the local disk instead of being pulled over the network.

How do users add their own packages? When each user starts Canopy from the same or similar core install, Canopy will create the user-specific virtual environments layered on top of the ones in /usr/local/Canopy/Canopy_64bit. This gives us the structure shown in the diagram below where Canopy Core and the common virtual environments are local to each node (ie, fast I/O access) and the user environments are on a networked file system.

Canopy cluster install

It should be noted that while the Canopy GUI may be available on the cluster one would typically not use the GUI on the compute nodes. Instead, the “User’s User” virtual environment can be used like a standard Python distribution, such as EPD, to execute the Python application. But the big advantage to this structure over a plain Python installation is that we have the performance advantage of having most of the Python packages local to each node while also providing an easy means for users to customize their environments. Users can run the Canopy GUI on their desktop to prototype an application and then run the same application on the compute cluster using the same package set — no additional configuration needed.

For more, get Canopy v1.1 and try it out.

EuroScipy 2012

EuroScipy 2012 starts tomorrow! Four days of exciting tutorials and talks. The conference is hosted in Brussels at ULB (which you probably know if you went to FOSDEM).

The first two days are dedicated to a great set of tutorials. The introductory track should please any new data analyst starting with Python:

  • array manipulation with NumPy
  • plotting with Matplotlib
  • introduction to scientific computing with Scipy.

In the advanced track, HPC and parallel computing are the main focus but tutorials also offer:

  • advanced numpy and scipy
  • time series data analysis with Pandas
  • visualisation
  • packaging and scientific software development insights.

 

Last but not least, the European Enthought team will offer:

  • a tutorial on Enaml, a new library that makes GUI programming fun
  • a tutorial on how to write robust scientific code with testing
  • a tutorial about Bento, a pythonic packaging system for Python software

Plan for an exciting weekend as well with various talks covering finance to geophysics to biology. Don’t forget to come for the keynote sessions with David Beazley on Saturday and Eric Jones, Enthought’s CEO, on Sunday!

 

See you in Brussels!

Enaml Pygotham Talk

Here’s the first video available from our Pygotham talk series. As mentioned in an earlier post, you can find the slides in this github repository. Enaml is an open source GUI framework that features declarative syntax and a constraints-based layout solver. The A/V was a little fragmented at the conference, so subsequent videos may feature screencasts rather than live-action video.

Thanks for watching!

Just released! EPD 7.3 plus beta version of EPD 8.0

Today we have for you not just one, but two exciting EPD releasesan update of EPD to 7.3 and a beta release previewing new features coming in EPD 8.0.

The EPD 7.3 update adds several new packages including Shapely, openpyxl, and a new package from Enthought named Enaml.  Enaml is a new package for rapidly building UIs using a very “Pythonic” declarative language heavily inspired by Qt’s QML langage.

EPD 7.3 also includes a host of package updates, including adding OpeNDAP support to the NetCDF4 package. Overall over 30 packages have been updated, including Cython, IPython, pandas, basemap, scikit-learn, Twisted and SQLAlchemy.

EPD 8.0 beta takes all that we know and love in EPD 7.x and adds an all-new graphical development and analysis environment.  The new GUI is focused on providing a fast, lightweight interface designed for scientists and engineers.  Some of the key features are:

  • A Python-centric text editor including tab-completion plus on-the-fly code analysis.
  • An interactive Python (IPython) prompt integrated with the code editor to enable rapid prototyping and exploration.
  • A Python package manager to make is easier to discover, install, and update packages in the Enthought Python Distribution.
  • Integrated documentation, both on the GUI itself and standard online documentation.

Which version should you install?  EPD 7.3 is the current production release and has the most testing behind it.  If you want to try out EPD 8.0 beta we would love to hear what you think.  EPD 8 is designed to work with earlier versions so once you install the GUI you can either setup a new EPD environment or tell it to use your existing one.  And don’t worry, it’s safe — it won’t modify your existing EPD.

As always, if you have an existing EPD 7.x install that you want to keep you can update all of the Python packages to EPD 7.3 by running the command “enpkg epd” from the command line.  Or, if you have installed the EPD 8 GUI, just open the package manager, select the ‘EPD’ package and click ‘Install’.  It will update you EPD 7.x environment for you.

EPD 8 can be downloaded from https://beta.enthought.com/EPD_8/download/.

Any comments, questions, complaints, or compliments on the beta release can be sent to beta-feedback@enthought.com.