Cookiecutter fails to install the project after a cookiecutter template was cloned

[jancura]

In latest Visual studio 2017I go to File --> New -->--> From Cookiecutter. Then I select an arbitrary template and click Run or Next. I see in the output window that the repository is cloned, but then I get an error, e.g.

----- Cloning template 'audreyr/cookiecutter-pypackage' -----
Cloning into 'cookiecutter-pypackage'...
----- Successfully cloned template 'audreyr/cookiecutter-pypackage' to 'C:\Users\pavol\.cookiecutters\cookiecutter-pypackage' -----
----- Installing cookiecutter -----
C:\tools\Anaconda3\python.exe returned an exit code of 1.
----- Failed to install cookiecutter -----

[huguesv]

Thanks! We'll need to make the check/install more robust.

This may be happening because Python was upgraded and potentially moved install location, and now the virtual environment we use is broken.

You should be able to delete that virtual environment and try again, it should recreate it successfully.

The folder to delete is %localappdata%\Microsoft\CookiecutterTools\env.

[jancura]

I have tried what you proposed, but it did not help. To give you more insights on my install configuration, I have installed Anaconda manually, not using Visual Studio, When I installed Python and Data Science workloads, I deselected Anaconda, since I had already my anaconda installation, but I kept Python 3.6 installation. So I have two Python environments, one installed manually (Anaconda in C:\Tools folder), the other installed via Visual Studio Installer (Python 3.6 in some VIsual Studio folder). Anaconda installation was automatically recognized by PTVS.

I choose Anaconda to be my default environment. That is why I assume cookiecutter is using python of Anaconda3, which fails. But if I changed my default environment to Python 3.6, cookiecutter was still using python of Anaconda3. Also, I had python of Anaconda3 in my PATH. I removed it, but it did not change the behavior of cookiecutter selecting Anaconda3 python.

[zooba]

That should be easy to check - if you go to the folder @huguesv mentioned above and find bin\python.exe then it's been created from Anaconda. We shouldn't do this, since they do some things "differently" that may be problematic.

I believe we actually look for the latest version of Python available, so if you selected the option in the Anaconda installer to make it the default it's now claiming to be a regular Python install and there's nothing we can do about it. As a workaround, you should be able to run these commands from a command prompt:

<path to Python 3.6> -m venv "%localappdata%\Microsoft\CookiecutterTools\env"
"%localappdata%\Microsoft\CookiecutterTools\env\Scripts\pip" install cookiecutter<1.5

This is essentially what our tool should be doing. Unfortunately, if Anaconda has overwritten the CPython registry keys, we don't have any way to do it automatically.

[jancura]

Indeed, my Anaconda installation made its Python the default (I used Chocolatey, which by default registers anaconda python as default python3). When I uninstalled Anaconda and installed with Chocolatey again but specifying not to register the default python, the cookiecutter was successfully installed and everything seems to work now.

Thanks for your help.

[zooba]

Hmm... I'm not sure how we can work around this situation. The VS installer deselects that option for you to avoid trouble, and recent Anaconda installers also have it deselected by default, so perhaps there's nothing for us to do?

@huguesv any ideas?

[ckhousemd]

I am having the same issue and also loaded Anaconda manually. I tried the commands from zooba but I don't have pip in the Scripts directory.

[zooba]

@ckhousemd Sounds like you ended up with a corrupt virtual environment. Delete the CookiecutterTools\env directory and try with a regular Python 3.6 install, rather than Anaconda.

[huguesv]

I just saw the same error on a machine where Anaconda was installed by the VS installer.

If I open a command prompt and do the equivalent (not the same target folder that cookiecutter uses for its venv)

C:\Users\huvalo>"C:\Program Files (x86)\Microsoft Visual Studio\Shared\Anaconda3_64\python.exe" -m venv "C:\Users\huvalo\Desktop\test\env"
Error: Command '['C:\\Users\\huvalo\\Desktop\\test\\env\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

https://github.com/ContinuumIO/anaconda-issues/issues/6917

I think at a minimum we could prefer CPython over Anaconda when available. That way at least we don't have to uninstall Anaconda to prevent cookiecutter from trying to use it. Right now it just sorts by Python version and picks the latest one.

[huguesv]

Since this is happening on the version of Anaconda that we install, we have to fix this. It's supposed to be fixed in Anaconda for their next release (according their comment in issue linked above).

My plan is to:

a. Prefer CPython over Anaconda for environment creation

b. If venv fails with error code 1 (I don't know if I can see the stdout/stderr, but if I can then look for 'ensurepip' error)

• try venv creation again using --without-pip
• download get_pip.py from https://go.microsoft.com/fwlink/?LinkId=616663
• run get_pip.py using env's python.exe
• continue as normal with installation of cookiecutter package

I verified that doing these steps manually works.

[zooba]

We should have a get_pip.py script included with VS that you can use without downloading it again.

[huguesv]

I didn't see a get_pip.py. We have pip_downloader.py which takes care of downloading it, but it saves it in a throwaway temp folder. Since pip_downloader.py doesn't depend on any other file, I could easily Add As Link and have it included in cookiecutter vsix, and just run that.

[zooba]

That's better than recreating the download logic. That script will also try ensurepip, which may skip the download altogether.