0

I've created a new test virtual environment in Enthought Canopy 1.1.1 (64-bit) using canopy_cli venv NEW_PATH as per the documentation, however when I run a binary installer such as the latest numpy, it doesn't find the venv as a place where the package can be installed.

What is a minimal set of changes I need to make to the registry for my venv to be recognized by a binary like the latest numpy? It would be nice if in a future update this was done automatically, or via a switch.

Finally, I had to run canopy_cli venv from the App environment, as when I run it from the default User environment I get the following error. Is this a bug?

C:\Users\Tim\AppData\Local\Enthought\Canopy\User\Scripts>canopy_cli venv
Traceback (most recent call last):
  File "C:\Users\Tim\AppData\Local\Enthought\Canopy\User\Scripts\canopy_cli-scri
pt.py", line 7, in <module>
    execfile(r"C:\Users\Tim\AppData\Local\Enthought\Canopy\App\Canopy-script.pyw
", ns)
  File "C:\Users\Tim\AppData\Local\Enthought\Canopy\App\Canopy-script.pyw", line
 757, in <module>
    bootstrap()
  File "C:\Users\Tim\AppData\Local\Enthought\Canopy\App\Canopy-script.pyw", line
 335, in bootstrap
    raise RuntimeError("no usable frozen versions were found")
RuntimeError: no usable frozen versions were found
Tim Rae
  • 3,167
  • 2
  • 28
  • 35

1 Answers1

0

1) If, in Canopy Preferences, you make Canopy your default Python, then Gohlke's binary installers, at least, do work without any manual registry edits. This "default" setting is not very robust at present, so if you have a PATH with other Pythons, it may not be able to handle this.

2) This may not be a complete answer, but 

HKEY_CURRENT_USER\Software\Python\PythonCore\2.7\InstallPath

should be set to 

"C:\Users\Tim\AppData\Local\Enthought\Canopy\User

3) Thanks for the report. There was such a bug, but it was (we think!) fixed in 1.1.0. If you have been doing updates in place since before then, the fix might not have propagated to the User environment. Are you willing to blow away your User Python (and all your package updates) to try to recreate it cleanly? If so, just delete that User directory. It will be recreated on next startup.

Jonathan March
  • 5,800
  • 2
  • 14
  • 16
  • Thanks for your reply, I was actually talking about a new non-default test venv; the User venv is already properly recognized by the Gohlke installer. However, I tried your second point, and simply temporarily changing the InstallPath key before running the installer was enough to get it recognized and run the installer. Is there no way to have multiple InstallPaths? I tried the third point and sure enough it fixed the problem... Is there a way to do this without wiping everything else though? – Tim Rae Nov 02 '13 at 07:13
  • There's an intrinsic contradiction between Windows registry-based configuration and more transient virtual environments. But it would indeed be useful to easily set registry to match a venv, and then revert. Logged for consideration. – Jonathan March Nov 03 '13 at 19:39
  • In theory we could have back-fixed to existing User environment, and in the future we will increasingly do so. Just a question of setting priorities. Glad that the blunt approach worked for you, and sorry for the extra work. – Jonathan March Nov 03 '13 at 19:42