Reputation: 1
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?
Upvotes: 0
Views: 739
Reputation: 5810
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.
Upvotes: 0