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.
Related
I'm using wsl and it runs codes in vscode pretty fine and I have different libraries which I installed through pip and conda in wsl but when I run that code using vscode itself it doesn't recognize the libraries or even pip itself.
I don't have any other environment.
I should add that I installed the packages globally using conda install ... or pip install ... in base environment and I only have base environment and I run my code through code . and I also have python and remote wsl extensions installed in my vscode.
what can be the problem?
I don't have much personal experience with this, but I found some useful information in this Stack Overflow question (even though it doesn't utilize conda), along with https://code.visualstudio.com/docs/remote/wsl-tutorial#_python-development.
I also found this blog post useful, even if it doesn't cover WSL.
In short, make sure you:
Have installed the Python extension (by Microsoft) in VSCode. This is critical for being able to detect and select the Python interpreter. You don't mention having this in place, so I believe this is your likely problem.
You have done this already, but including it for others who might read this later -- Install the Remote - WSL extension (or the Remote Development extension pack) in VSCode.
You are also doing this already -- Start VSCode from inside your WSL distribution. Alternatively, you can start VSCode from Windows and then select the Remote WSL - Reopen Folder in WSL from the Command Palette (also accessible from the "Remote" Status Bar).
In VSCode, open the Command Palette with Shift+Ctrl+P, search for the Python: Select Interpreter command, and you should find your Conda environment in the list.
After selecting this, you should find that your project is using the interpreter and modules that you have installed via conda.
One thing I did to overcome this issue is go to Extensions -> Local (You should have two tabs there, Local and WSL:DISTRO) DISTRO refers to whatever DISTRO you're using, you will see that some of the local extensions are disabled in the current workspace (WSL) and there is a little cloud icon in the WSL:DISTRO tab that says install Local Extensions in WSL:DISTRO once you click that it will let you choose which extensions to install and you should be good to go!
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.
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.
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. :)
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)