This section lists major uncorrected issues known at release time. Where possible, we suggest workarounds.
Summary of release notes
Canopy’s python distribution has been updated to 2.7.6 from 2.7.3. This is a minor patch release to Python meaning that all existing 2.7.3 code is expected to run the same as before. Please see this Enthought Knowledge Base article for details.
Support for Microsoft’s Python Tools for Visual Studio (PTVS) was introduces in Canopy 1.2. An issue with finding a debug symbol library makes the mixed-mode debug option harder to use. This has been corrected in 1.3, details can be found in this knowledge base article.
In some cases, the Package Manager UI would show an available update to one of the Canopy packages, but no option was provided to install the package. This issue is resolved and details are available in this knowledge base article.
A change in the latest Mac OSX version “Mavericks” caused Qt to select the wrong system font, and thus the display font in Canopy wasn’t right. We have applied a patch to Qt to correct the issue and the fonts should display correctly now.
In some situations Canopy on OSX could run into a deadlock when trying to exit the application. This would cause Canopy to still be shown as a running application even though it had been terminated. When performing an update, it would also cause a dialog to appear asking you to kill the existing Canopy processes. A workaround has been added to avoid the deadlock so Canopy can exit cleanly in a timely manner.
The PySide package has been updated to verison 1.2.1 with some additional community fixes added to Enthought’s builds. These changes improve the stability of the Canopy GUI. Users writing Python code that uses PySide and Qt should note the change as well as this change updates the user-visibile versions as well. No compatibility breaks are expected.
In Canopy 1.3 (and 1.2), there are several issues with virtual environments created with the Canopy CLI or directly with venv. These issues should be fixed in the Canopy 1.4 release. Please see this Knowledge Base article for more information.
Python Tools for Visual Studio is a free, open-source plugin which adds Python suport to the Microsoft Visual Studio development environment. Visual Studio with PTVS is a professional software development environment ideal for users and teams who need to develop and debug significant applications, especially those with mixed Python/C++/C environments. This compares with the Canopy analysis desktop which is tuned for scientists and analysts working with Python scripts and smaller applications, especially for interactive work with the IPython console and other analysis tools.
Canopy has been extended with native PTVS integration, allowing PTVS to automatically recognize Canopy. To examine the Python enviroments detected by PTVS, in Visual Studio go to TOOLS -> Python Tools -> Python Environments. Canopy is shown as “Enthought Canopy”.
The PTVS completion database will need to be refreshed from the Python Environments window before the first use to enable full code completion. Similarly, after new Python packages are installed via Canopy’s Package Manager it is necessary to refresh the completion database before the new packages will be available for completion.
Canopy supports PTVS under Visual Studio versions 2010, 2012, and 2013.
The latest release of Apple’s Mac OS operating system code named “Mavericks” causes some compatiblity with the interactive IPython prompt and with IPython Notebooks. The issue causes both to run extremely slowly. If possible we recommend not updating your OS until the issuss are understood and resolved.
For users who are running Mavericks, Canopy 1.2 includes a fix that addresses most or all of the issues in the interactive IPython prompt and in IPython Notebooks. For ongoing status updates, see https://support.enthought.com/entries/22861925-OS-X-10-9-Mavericks-Python-Canopy.
The ‘pip’ command provide access to Python packages available on the PyPI repository and through other sources. This command has always been available to be installed via the ‘enpkg’ or ‘easy_install’ commands. With Canopy 1.2 ‘pip’ is now installed by default. The command can be found in the User\Scripts directory on Windows, or User/bin on Linux and Mac OS.
Note: users with existing Canopy installations will still need to install it manually if desired. The command to install ‘pip’ is:
The easy_install command can be found in the User\Scripts directory on Windows or User/bin on Linux and Mac OS.
The PySide and Qt installations within Canopy have been upgraded to include the respective developer tools such as ‘qmake’ and the UIC compiler. These tools can be found in the core Canopy installation tree. The “Core” installation is the location where Canopy is initially installed. See Where are all of the Python packages in my User Python Environment? As a reminder, you never run Python directly from Core (except to start Canopy itself), but rather from a User environment which inherits from Core.
This error typically occurs when the 64-bit Canopy install is run on a 32-bit Windows system. Users on 32-bit machines should make sure they select the 32-bit installer when downloading Canopy from https://www.enthought.com/downloads.
This error occurred primarily on Windows systems and was the result of the preferences.ini file becoming corrupted. On earlier versions of Canopy the workaround is to exit Canopy and delete the preferences.ini file located in each user’s account.
Canopy 1.2 detects malformed preferences files, renames the file with a ‘.bak’ extension, and then loads with the default preferences.
The environment variables HTTP_PROXY and HTTPS_PROXY are used on most operating systems to specify the host, port, and (optionally) a username and password of a proxy firewall to use when connecting to the internet. Many organizations use such servers. Canopy will honor these settings when making outgoing connections unless they are overridden from the Canopy preferences dialog.
Both environment variables are expected to be set to a value URL. For example:
In previous releases if either environment variable was set to an invalid URL Canopy would fail to start. This release partially corrects this behavior to ignore the invalid value, but the error is only reported in the log file ‘main.log’ (i.e., the user is not notified directly).
When using the canopy_cli venv command to create a new virtual environment, if the target directory is specified with a relative path, any scripts in the ‘/bin’ directory of the new virtual environment would have the wrong path to the Python interpreter (the “#!” line at the start of the file).
This issue was corrected for some virtual environments in the previous release and has been completely corrected now.
The Canopy_cli.exe command supports setting up and configuring Canopy environments from the command line, enabling deployment automation. The –no-gui-setup switch turns off GUI interactions for command line usage. In the previous version the command still showed a progress dialog, causing the command to fail on headless servers.
This issue has been resolved.
The 32-bit Canopy 1.1 installer incorrectly included a 64-bit binary version of the canopy_cli executable. This prevented the command from running on 32-bit system. This has been corrected.
When Canopy is set as the default Python environment on Windows it sets the following standard Python registry keys:
These are set to point to the User python environment and the Python executable under User, respectively. These keys are used by many third-party tools to integrate with Python.
Previous releases of Canopy did not set the second registry key, PythonPath. This value can be set in current installations by going to Edit -> Preferences and clicking ‘Set as Default’.
From the Mac OS command line, files can be opened directly in the Canopy editor via the ‘canopy’ command like this:
This will open the file ‘myfile.py’ in the currently running Canopy instance or, if Canopy is not running, will start Canopy then open the file.
In Canopy 1.1 and 1.1.1 this command would fail when given a relative path to the file. This has been corrected.
On many Linux systems Canopy would issue this warning at startup. The warning was harmless and could be ignored and is no longer shown in Canopy 1.2.
After tremendous work, the IPython team and community achieved their 1.0 release, quickly followed by version 1.1, with even more features. The Canopy GUI’s integrated IPython prompt in the editor window now uses IPython 1.1.
Please note that when ipython is run from an OS command prompt (terminal or shell), it will be whatever IPython version is installed in the Canopy User Python environment. This version may or may not match the IPython version used in the Canopy GUI itself, and can be independently changed. To install IPython 1.1 or any other version for use from the OS command line, go to the Canopy Package Manager and update the IPython package.
We are investigating an issue in the integration between the code editor and the Qt text editor widget that can cause Canopy to crash when using the code completion feature (‘tab’ to complete symbol names). The failure happens rarely, particularly when ‘tab’ is pressed several times in quick succession, and appears to be timing-dependent. We can reproduce the crash and are investigating, with a target of fixing it for the 1.2 release in early November.
When using the canopy_cli venv command to create a new virtual environment, if the target directory is specified with a relative path, any scripts in the ‘/bin’ directory of the new virtual environment will have the wrong path to the Python interpreter (the “#!” line at the start of the file). This path must be manually corrected in order for the script to work correctly.
This issue has been corrected for any virtual environments created, from now on, which are based on the Canopy User environment.
However, when such virtual environments are created from the core installation directory specifying a relative target path, the resulting scripts will still be incorrect in Canopy 1.1.1.
Workaround: to avoid having to manually edit the “#!” lines in these scripts, always specify an absolute path when creating such virtual environments.
This defect will be corrected in the 1.2 release planned for early November. Note that any scripts already created incorrectly will not be fixed, and must be manually corrected, or the virtual environment re-created.
On Windows, this option pops up a dialog, thus breaking installation automation. This will be fixed in Canopy 1.2. If you need a simple fix for this sooner, please contact email@example.com.
At startup Canopy would begin to show the splash screen and then abort with no error message. The log file would only show the following message:
QtWarningMsg: fatal IO: client killed
The problem has been tracked down to an issue with some older X Window System servers which appear to be unable to handle high-resolution application icons. We have changed the icon and Canopy now works correctly on all tested X servers (including XMing on Windows) and VNC servers. Please report any continuing issues to firstname.lastname@example.org.
After a crash or forced quit of Canopy, users were sometimes unable to restart Canopy without manually deleting several lock files in the user’s preferences directory. Canopy should now delete these files when appropriate.
During the update process, Canopy will sometimes report that stray Python processes are still running and need to be closed before Canopy continues. This is primarily an issue on Windows where running processes often hold locks on files, thus preventing some files being updated. Canopy will prompt to terminate these processes before continuing. We are working to eliminate stray processes caused by Canopy’s operation; some are caused by execution of user code.
In some cases the dialog showing the remaining Python processes would cause Canopy to crash due to Unicode (non-English characters) in a path name. This issue has been resolved and Unicode characters are handled correctly.
The ‘About Canopy’ dialog box offers the option to check for application updates. In the previous release if no updates were present the ‘spinner’ indicating that a check was on-going would continue spinning for several minutes after the last check. This has been corrected.
In the previous release, an IPython Notebook would fail to open a local file when an HTTP proxy is set. The issue was that references to localhost were incorrectly passed to the proxy server as well.
On Windows and Linux this issue has been corrected. The issue is still open on Mac OS and will be corrected in the Canopy 1.2 release in early November.
A new command line interface (CLI) has been added for users who prefer to work from the command line, are writing automation scripts, or working on a machine without a graphical interface. The CLI supports setting up Canopy installations in networked environments where users wish to share a common environment, and creation of new virtual environments.
See Canopy Command Line Interface for details.
For each OS platform, two versions of the Canopy installer are now available to subscribers. These differ only in the number of packages which are bundled into the installer file for immediate installation into Canopy User Python, when Canopy is first started. Canopy’s Express installer contains approximately 40 packages, including the entire core SciPy software stack. Subscribers can subsequently install additional packages as needed, via Canopy’s Package Manager. Canopy’s Full installer contains all 140+ Canopy packages.
The Express installers work well for subscribers who want to avoid installing unused packages. Likewise, if you started as a free Canopy Express user, and are now a subscriber, you can simply use Package Manager to add subscriber packages as needed. The Full installers are for subscribers who want to install all packages immediately, including those who are installing into environments with limited or no internet connectivity. The difference in installer sizes and disk usage is given below.
|Platform||Express Installer||Express Disk Usage||Full Installer||Full Disk Usage|
|Windows||230 MB||900 MB||380 MB||1400 MB|
|Linux||280 MB||1180 MB||420 MB||1800 MB|
|Mac OS||230 MB||870 MB||350 MB||1550 MB|
One aspect of the new command line interface is support for non-GUI installs. This comes up when users don’t have access to a Graphical User Interface on their machine (such as when connecting via ssh), prerfer the command line, or need to automate the installation on a network or cluster environment.
The new canopy_cli utility supports a new switch --no-gui-setup which guides you through the setup from the console. See Setting up the User environment without a GUI in the Users Guide for more details.
Canopy for Linux is now out of beta and in full production. Canopy is supported on RedHat Enterprise 5 (and compatible) systems and Ubuntu 12.04 LTS. In general, Canopy typically works without issue on RedHat Enterprise 6 (RH6) systems and other distributions. In particular, full support for RH6 is coming after additional testing on RH6 systems.
The Documentation Browser previously identified code segments in documentation and added icons for opening the code in the Canopy editor or executing the code in IPython. A potentially malicious webpage could have been crafted such that it automatically executed the Python code without the user taking action. This would only happen if the user navigated to the malicious page by entering a URL in the Documentation Browser’s address bar.
The previous version of Package Manager did not support a means of interrupting the download or install of a batch of packages. For large packages, or a large number of packages such as when “Install All Canopy Packages” was pressed, this could take a long time to complete, especially over slower Internet connections.
This has been corrected and there is now a ‘Cancel’ button on the UI.
On multi-user systems it is now possible to configure system-wide default preference settings. The preference file is the same format as the per-user preferences.ini file (see Where are the preference and log files located?). The system preference can be set by creating a preference.ini file (or copying a per-user one) to the root installation directory of Canopy. The default path to the root installation directory is shown below by operating system.
|Operating System||Default path|
|Windows||C:\Program Files\Enthought\Canopy\App or see per-user install paths|
In some cases Canopy would fail with the error “Failed to set up your environment”. This error could be triggered when the user’s home directory was stored on a network drive. The issue has been corrected.
In the About Canopy dialog box, when an update was available clicking ‘Install on Quit’ could cause Canopy to abort. This was caused by an error in the code that closed the GUI and particularly showed up under Linux. This issue has been corrected.
The Canopy command can be used on all platforms to open files from the command line simply by adding the name of a file to the command line. For example:
In the previous release, the file was opened using the case as typed on the command line instead of the case of the file itself. On case-insensitive file systems such as on Windows this worked correctly. However, it was then possible to have the same file open multiple times in Canopy, resulting in a confusing display. This has been corrected and the file is opened with the actual case of the file itself.
The MSI version in previous releases was not correctly tracking the actual Canopy version installed. This has been corrected and is reported as ‘1.1.0’ for this release. The MSI version will reflect the version of Canopy installed via an MSI, which may be an older version than is running if Canopy updates have been applied.
From Canopy you can create new virtual environment with the canopy_cli venv command. In the past venv supported nesting two layers deep. This restriction has been removed and it is possible to create arbitrarily-nested virtual environment.
canopy_cli.exe venv -s C:\venv1 C:\venv1\Scripts\venv.exe -s C:\venv2 C:\venv2\Scripts\venv.exe -s C:\venv3
In this example, since the -s switch is provided, venv3 can import any package that is installed into venv3, venv2, or venv1.
A common scenario for using nested virtual environments is to experiment with package changes without impacting a stable, working environment. For example, is venv1 is being used for a project and is work, venv2 can be created as above and it starts out with all of the packages from venv1. Then alternate package versions can selectively be installed in venv2 and code run it in for testing without impacting venv1.
The previous release would frequently hang when applying some types of Canopy updates when “Install and Relaunch” was used. This update corrects the issue in advance of the 1.1 release.
Under rare circumstances, the ‘modified’ flag in the text editor is incorrectly set to ‘unmodified’. This results in no changes being saved when File -> Save is used and Canopy will not warn of unsaved changes before exiting. This can result in a loss of any edits made in the tool.
This issue has been corrected and we recommend all Canopy users update from 1.0.3 to 1.0.4.
The preferences dialog (Edit -> Preferences) displays an informational message if Canopy is not currently configured as your default Python environment and provides a button to set up your environment to make it the default. In Canopy 1.0.3 on Windows this informational message is sometimes displayed when Canopy is the default environment, even after clicking the button to make it so.
This issue has been resolved and the detection algorithm has been improved. The display now also includes information indicating if another Python environment has been configured in the system PATH specification, making it so Canopy cannot be made the default.
Proxy firewalls are used by many organizations to control traffic to/from their networks and require that applications connect through the proxy server in order to access resources on the Internet. Canopy now supports preference items for configuring proxy support, available under Edit -> Preferences (Canopy -> Preferences on Mac OS). See the ‘Network’ tab.
The previous version of Canopy did not set a standard registry key that many third-party installers and Python tools use to find the default Python environment on Windows systems. As a result, non-Enthought Python package installers such as those produced by Christoph Gohlke were unable to install packages into Canopy. This has been corrected. When Canopy is made the default Python environment these installers should now find the User Python Environment.
When Canopy was installed to an NFS4-mounted file system under Linux the installation had the uid and gui set to “506”. This has been corrected and when the files are now extracted using the ‘tar’ command the -no-same-id flag is passed.
When applying an update to Canopy at times it would appear to “hang” at 98% or 100% complete and not return. This was a UI issue where the progress bar reflected the download process, but not the installation process, which could sometimes take several minutes or more. The UI has been changed to reflect the separate operations of download and installation.
A context-sensitive (right-click) menu item now allows the recent files list in the code editor navigation tree to be cleared. A second menu item allows any missing / deleted files to be cleared. Additionally, individual files can be removed from the list by right-clicking on the item.
A combination of build errors caused some or all of the Tkinter (and Tck/TK dependencies) to be missing on Windows, Mac OS, and Linux installations. In some cases this would cause Tkinter to not import, and in others the package would import but would fail during usage. This has been corrected and Tkinter should function correctly on all platforms.
On Windows the environment variable %HOME% is not always set, and is sometimes set by third-party applications. If %HOME% is set to something other than your home directory, or particularly to an unwritable directory, Canopy would fail with an Unexpected Error during initial setup. This has been corrected.
By default Canopy automatically checks for and downloads product updates as they become available. These updates are not installed until explicitly done so by going to Help -> Canopy Application Updates...
A new preference item has been added to disable the automatic downloading of updates for users with limited or metered Internet access. Updates can be explicitly downloaded by going to Help -> Canopy Application Updates... and clicking ‘Check for Updates’.
Attempting to run a file in the IPython prompt (Run -> Run File) that has not yet been saved and contains unicode content would result in an Unexpected Error dialog. This has been corrected.
On Mac OS Canopy sets the DYLD_FALLBACK_LIBRARY_PATH so modules can find shared libraries in the user Python environment as well as the core application install. The default for this environment variable was set incorrectly so some modules failed to find the C library. This has been corrected.
Canopy depends on the library libjpeg62 to read JPEG-format images. Previous releases did not include this library and depended on it being available on the user’s system. However, this version is old enough that some Linux distributions no longer provide it. Canopy now includes this library.
The previous version of Canopy was missing some libraries necessary for SSL/TLS support, and thus the ability to display secured HTTP (HTTPS) pages in the documentation browser. This would cause the pages to show a network error. This has been corrected and HTTPS pages now display correctly in Canopy.
White space (spaces, tabs mostly) at the end of lines of programs doesn’t usually have an effect, though many programming editors automatical remove it. If some editors remove it and some don’t, this can cause problems when comparing two versions of a file if the comparison utility doesn’t ignore white space differences.
An option has been added to the Preferences dialog under the ‘editor’ tab to automatically strip white space at the end of lines. This occurs whenever the file is saved. By default, this option is off for compatibility with previous Canopy versions.
NOTE: Please look for the Canopy 1.0.3 release following closely after 1.0.2
A defect in previous releases could cause the installation of Canopy updates to hang and fail if Canopy was installed using escalated privileges. For example, this could happen if Canopy was installed as an Administrator user but tries to apply the updates when running at standard user access levels. The issue would occur when Canopy attempted to request increased access levels from the OS (Windows, Linux, or Mac OS).
The 1.0.2 release fixes this issue in preparation for the 1.0.3 release. As such, 1.0.3 will only be visible after 1.0.2 has been applied.
An indicator showing when Canopy updates are available has been added to the Welcome Window. A green update indicator will be shown in the bottom right corner of the window.
In-app registration via the Canopy welcome screen fails with a “403: forbidden” error. This has been corrected and registration should now work correctly. The workaround for previous versions is to register for a user account directly at https://www.enthought.com/accounts/register/ and then log in via the Canopy welcome screen.
The Canopy Package Manager supports in-app purchases of subscriptions to the package repository. This is done by displaying the Enthought.com purchase web page in the application. After some updates to the website, the purchase URL was not correctly updated and resulted in a “page not found” (404) error. The URL has been corrected and the purchase page displays correctly now.
In the previous release, packages such as Pip that install command line utilities were installed using the wrong Python executable when installed via Package Manager. Instead of using Python from the ‘User’ virtual environment, the Pythone executable from the ‘System’ virtual environment was selected. This resulted in Python packages potentially being installed in the wrong environment or Python not finding an installed package.
This release corrects the issue and automatically fixes any incorrectly installed packages.
Canopy now has very basic, experimental support for connecting through proxy firewalls. This functionality is still being tested and is being made available for users who require it and wish to help test it and provide feedback.
The proxy support enables the Package Manager, Canopy software update fuctionality, and Documentation Brower to make HTTP and HTTPS connections when connecting through some common proxy server configurations. The proxy functionality can be configured in one of two ways: by editing the Canopy preferences.ini file or by setting an environment variable.
To edit the preferences.ini file, follow the following steps:
Exit Canopy. This is important because Canopy overwrites the preference.ini file on exit.
Now using a standard text editor, open preferences.ini (see See Where are the preference and log files located? for the location of the preference.ini file on each OS) and add the following lines:
[main] proxy_server = *server_name* proxy_port = *port_number* proxy_username = *username* proxy_password = *password*
The values proxy_server and proxy_port must be set to the name of the server and the port number to connect to. The proxy_username and proxy_password settings are optional and only need to be provided if your proxy server requires authentication.
Important: If you set proxy_password you will be storing your password in plain text which is insecure. In some environments this password is regularly set in environment variables and is considered insecure already so this is not an issue. If the password is expected to be secure it should not be set here. Future Canopy versions will correctly store this password securely.
Once these changes have been made, save the file and restart Canopy. When the Package Manager is opened it should now be able to correctly download the index of packages and install new packages.
As an example, a typical configuration looks something like this:
[main] proxy_server = proxy.myorg.com proxy_port = 8080 proxy_username = proxyuser proxy_password = passwd
Canopy is now supported on Linux as well as Microsoft Windows and Apple Mac OS. Canopy is supported on Ubuntu 12.04 and RedHat Enterprise 5 and 6 though should work on most Linux distributions.
The Linux version of Canopy is still in beta but contains all of the functionality of the Windows and Mac OS versions.
The Canopy installers include the core SciPy software stack and other packages listed in the Canopy Express version. When Canopy is installed all of these packages are installed in the user Python environment.
Subscribers have access to the full Canopy Python repository via the Canopy Package Manager. Additional packages can be installed individually as needed or users can install all available packages. To install all packages, click the button labeled “Install All Canopy Packages” found in the lower-right corner of the Package Manager window. This option is available to Canopy (EPD) subscribers.
Canopy does not currently support proxy firewalls. Please see How do I use Canopy when behind a proxy firewall? for more information.
In Mac OS 10.8 Mountain Lion, Apple introduced a feature called “Gatekeeper” that restricts unidentified applications from installing and running. The Canopy application has not yet been been added to the Gatekeeper identification system.
As a result you may see a message like this if you attempt to start the Canopy application:
To open Canopy the first time, you need to Control-click the Canopy application icon to bring up a context menu, and select “Open”. You will then see a dialog which has a message:
Click “Open” and Canopy will start.
You only need to do this once. After this you will be able to start Canopy application normally by double-clicking its icon.
When Canopy is run for the first time, it setups up your Python environment and offers to make Canopy the default Python environment. It does this by pre-pending the location of Canopy’s Python interpreter to the front of the PATH environment variable. In most cases this has the desired behavior and makes Canopy the default for the Windows Command Prompt and other terminals.
This method does not work if another application with Python has been installed on the system by an administrator and the path to that application has been added to the system PATH setting. Windows first uses the system’s PATH setting and then the user’s PATH, so the other application will be found first.
The workaround is to manually adjust the system PATH setting if possible. Alternately, PATH must be set once the Windows Command Prompt has been started.