Recent Canopy update breaking python path? - enthought

I am wondering whether a recent Canopy update (I am now on 1.1; Windows 7 x64) somehow broke my python path. I can no longer import packages that have been installed from the command line (and therefore ended up either in C:\Users\USERNAME\AppData\Local\Enthought\Canopy\System\Lib\site-packages or in C:\Users\USERNAME\AppData\Local\Enthought\Canopy\User\Lib\site-packages), which worked just fine before the update. Interestingly, the PyLab link that is installed by Canopy also fails ("No module named matplotlib"). Any suggestions how this can be fixed?

Any packages that you installed into Canopy\User should still be importable. Any packages that you installed into Canopy\System will not be, starting with Canopy 1.1. Actually, these should never have been installed there, because System is only for internal use by the Canopy application itself.
What has changed is that we are now more strongly enforcing the rule that external packages should only be installed into Canopy User Python:
https://support.enthought.com/entries/23389761-Installing-packages-into-Canopy-Python-from-the-command-line
For more on the layout of the virtual environments, see:
http://docs.enthought.com/canopy/configure/faq.html#where-are-all-of-the-python-packages-in-my-user-python-environment
Topologically, Canopy System Python has been a child of Canopy Core Python in both Canopy 1.0 and Canopy 1.1, whereas Canopy User Python changed from being System's child in 1.0 to being its sibling in 1.1. With this change, we lost a little disk space to duplicate packages, and gained a lot more robustness.
The end result is that with Canopy 1.1, System is no longer on Canopy User Python's sys.path.
Bottom line: I suggest quitting Canopy and deleting the System directory, so that it will be re-created cleanly on next restart. Then install your "missing" packages into User, per spec.
Hope this helps.

Related

Enthought Canopy does not start after upgrade

I have been using Enthought Canopy for quite a while now with the academic license. Till today it was working fine, today I got the request to update Canopy. I assume to version 1.7 since that seems to be the latest. After installing and restarting the computer no error message but Canopy does not open anymore. Just nothing happens when I try to open Canopy, Package Manager, Code Editor nevertheless the Canopy cmd seem to be fine.
Now it is getting interesting, I can still start Ipython/Jupyter notebooks via regular win cmd and run python scripts with Canopy. Although the files are no longer marked as to be opened by canopy with the blueish symbol and do not open on click or double click as before.
import sys
print sys.prefix
C:\Users\MYNAME\AppData\Local\Enthought\Canopy32\User
Consequently, I can work and I am hesistant to try fixes since I am afraid to make it even worse. Reinstall is is only okay if I can get back all my installed libraries with ease.
However, I found very convenient to use canopy since I was able to start ipython notebooks directly in the file explorer by double click instead of going through the cmd. Furthermore, the Package Manager is also a quite handy tool, I really would like to have both back working fully.
Thank you for your suggestions:
System:
Windows 8, 64-bit operating system
Installed Version of Canopy:
`Canopy32\\App\\appdata\\canopy-1.6.2.3262.win-x86\\lib`
(consistent in sys path and control panel - program and features)
The Canopy Support Directed me to a working solution:
Note, uninstalling Canopy does not affect your installed package set.
You have two choices:
A) It would be cleanest to start with the up-to-date package set in
Canopy 1.7.
To do that, then after you uninstall Canopy 1.6, but before you
install 1.7, delete directories:
C:\Users\MYNAME\AppData\Local\Enthought\
C:\Users\MYNAME\AppData\Roaming\Enthought\ B) However if you have a
number of non-Enthought packages installed into Canopy, which would be
troublesome to re-install, you could choose to delete the above
directories and their subdirectories, with the exception of this
directory C:\Users\MYNAME\AppData\Local\Enthought\Canopy32\User\
which is where your existing packages are installed.
If you do this, then after restarting you'll be running Canopy 1.7 but
with your pre-existing package set from Canopy 1.6.2.
I chose to deinstall 1.6. and install 1.7.1 and I did not delete the directory with the external libraries.

IPython notebook kernel dies on import

I am running IPython Notebook on Enthought's Canopy 64 bit distribution, Ubuntu 14.04.
I've tried install libtiff, but when I import it in IPython Notebook, the kernel always dies at the import statement. What could possibly be causing this? Canopy is my default Python distribution, my paths all seem like they're set up appropriately, although I'm convinced that something in my Python setup is borked.
Any advice is appreciated.
EDIT: I'll be more specific. Output of sys.path:
['',
'/home/joe/Enthought/Canopy_64bit/User/src/svn',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python27.zip',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/plat-linux2',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-tk',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-old',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-dynload',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/PIL',
'/home/joe/opencv-2.4.9',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages/IPython/extensions']
As for how to install Python packages, I assume I go to ~/Enthought/Canopy_64bit/User/lib/python2.7/site-packages and run pip, setup.py, or a shell script, per the specific package's instructions. Is that correct? The article that I linked has the following line: "To install a package which is not available in the Canopy / EPD repository, follow standard Python installation procedures from the OS command line.", which seems to imply that I install per package instructions.
In .bashrc, I have the following:
VIRTUAL_ENV_DISABLE_PROMPT=1 source /home/joe/Enthought/Canopy_64bit/User/bin/activate
export PYTHONHOME=/home/joe/Enthought/Canopy_64bit/User/bin
export PATH=/home/joe/Enthought/Canopy_64bit/User/bin
export PYTHONPATH=/home/joe/Enthought/Canopy_64bit/User/bin
From what I understand of the linked articles, this means I'm setting Canopy User as my default Python distribution. I'm sure I'm doing something a bit over my head here, but I can't understand what else I need to do to fix this issue.
Worse yet, now I'm getting an "ImportError: No module named site" with these .bashrc settings, when trying to start IPython notebook or python from the command line. I can run only from the Canopy GUI.
Closing this. I made it harder than necessary.
It turns out, the PYTHONHOME and PYTHONPATH .bashrc variables were causing some conflicts. Commenting them out seems to have resolved the issue.
Installing outside packages does, indeed, happen from the home (~) directory.

Import error when using a python script that do not occur in ipython

All my install for python were working pretty well since soon. Now, I have a weird issue that generates import errors for some of my Python scripts and when using Ipython those import performs as expected.
This issue does not depend on the working dir (tested this several times with the same result). And I didn't change anything in my .bashrc regarding PYTHONPATHs.
So this might be a noob question, but is there an option in Ipython to display everything Ipython is doing when I run a command, so that I can track which is the package Ipython succesfully imported?
The packages I have trouble with are actually yaml, matplotlib cloud Image. Is it possible that an update from 2.6 to 2.7 is responsible for that? (I work on OSX Lion and most of the packages are installed via macports and updated using the upgrade outdated command).
As I think I can probably fix this myself with the command I asked for, don't bother seeking further for package compatibility or anything if you got the Ipython command that might suits me.
The difference of imports between python and ipython resulted from a cross defined python reference library (when installing most of the python libraries with macports and some without any known ports with other package managers).
Reinstalling the whole python libraries using the process described in http://astrofrog.github.io/macports-python/
corrects the issue and it is preferable to install manually the libraries that don't have any known ports (for instance with a setup build/install process).

Installing Canopy in OSX and Linux in same home directory

I have a networked home directory, which is used by linux and OSX machines. I want to install the linux and OSX versions of Canopy so that I can use it from any machine.
I first installed the linux version by running the '.sh' file. Despite asking where I wanted to put Canopy, the installer puts most of the stuff in ~/Library/Enthought/Canopy_64bit/. This is a problem because later, when I try to install Canopy in OSX, it just assumes again that Canopy is in ~/Library/Enthought so somethings will be overwritten but other binaries will be kept untouched, and the whole thing doesn't work in OSX or Linux.
Is there a way to force the linux version to be installed somewhere else? From the documentation it seems that it used to be ~/Enthought, but it doesn't work for me.
I suspect the problem is with having your locations.cfg file in ~/.canopy which is shared by both the versions of Canopy. Can you try the following:
Install the Linux version of Canopy and run it.
Remove your ~/.canopy/locations.cfg
Install your OSX version, and see if that works?
When you go back to running your Linux version, it'll again prompt you for install locations for the user environment, where you could select the old Linux install location.
Even if this works, I'm not sure, this would be too convenient. Let me know, how it goes. :)

Can't launch IDLE after installing Enthought Canopy

I was previously running Enthought EPD 7.3.2, but switched over to Canopy (academic license). I completely uninstalled EPD before running the Canopy install.
After installing Canopy, I have a shortcut to IDLE in the Canopy start menu folder, but I can't get it to launch (I click it and nothing happens). Tried uninstalling and reinstalling Canopy, but am having the same issue.
Running the 64-bit version of Canopy on Win7, 64bit.
I had a similar problem and found a very simple solution. Try it out and see if it works in your situation too. There is a directory for the Canopy installation:
C:\Users\\AppData\Local\Enthought\Canopy\App\appdata\canopy-1.7.4.3348.win-x86_64\Lib\idlelib
Find “idle.ico” file there, copy and paste it into “Icons” subdirectory.
This fixed the problem!
Canopy 1.0 and 1.0.1 versions have problems with tcl and TKinter, and IDLE doesn't work. This should be fixed in an update, which is just round the corner.
As an afterthought, is there a specific reason you wish to use IDLE? Canopy's editor comes integrated with an IPython console (along with many other goodies), which gives a much better user experience while programming, IMO. (Disclaimer: I work for Enthought)