make script compatible to pypy / having scripts in bin

[wamserma]

I had a take on #30
Works for me, had no issues so far.

[thebjorn]

Hi @wamserma and thank you for the PR, it's really appreciated.

I see a few problems that needs to be fixed before I can merge this.

pypy --version >nul 2>&1

This will always succeed for users that have a (default) pypy installed on %PATH%, so it isn't a valid test for whether the current virtualenv is using pypy.

As an aside: if errorlevel might not function as you're expecting (https://ss64.com/nt/errorlevel.html)

Escaping env vars: You are defining a couple of environment variables that escape to the user's environment after the script is run (e.g. PYTHON_EXE, LIB_DIR). That is bad, e.g. if a user has LIB_DIR pointing to their c++ lib folder and calls cdsitepackages.. suddenly the environment variable is gone (or points to a different directory).

We have a number of environment variables that historically have escaped (e.g. _LAST_DIR, PYHOME, WORKON_HOME, etc.). These must stay for backwards compatibility reasons. For everything else we need to clean the variables from the environment before exiting. The method I have chosen involves using a per script prefix:

    set "vwfooscript.my_var=%~1"
    set "vwfooscript.my_other_var=%~2"

and then clean them up at the end using a for loop:

:cleanup
    for /f "usebackq delims==" %%v in (`set vwfooscript.`) do @set "%%v="
    goto:eof

(I've started to document some of this on the docs branch if you're interested, e.g.: https://github.com/davidmarble/virtualenvwrapper-win/blob/docs/docs/codingstyle.rst)

Duplication: There's a lot of duplicated setup code. This isn't your fault (at all), but your additions certainly puts a spotlight on this problem. For a while I've toyed with creating a script that would run the setup code and could be called from every other script.

I've just pushed such a script now (scripts/vwenv.bat). It's not used anywhere yet, but maybe it would make this PR cleaner..?

NB: As per now, the vwenv.bat script doesn't account for the situation where virtualenvwrapper-win has been installed in a pypy-based Python. (I see you're detecting this in a couple of places).

Bookkeeping: You should add a bullet in CHANGELOG.rst (it can be as simple as "added pypy support @wamserma ")

[wamserma]

Mmmh yes, this was just a quick batch edit to get things rolling for me. To be honest, I always assumed that one was checking for the availability of pypy.exe outside of the VirtualEnv.
Regarding the escaping vars, I was reluctant to use SETLOCAL as I expected things to break then.
Pretty much the same thing with the duplicated code: I wanted to get things running quickly. How about using some sort of preprocessor to plug things together?
I also wasn't able to test this properly. I simply wanted to have some comfort for virtualenv on a system where I only unzipped pypy and added it to the path.
For now, I will add the bullet to CHANGELOG.rst and look into the other issues as I have time.

Edit: Regarding errorlevel, I know that this is a GTE-check. I'll put it on the review-list, though.

[thebjorn]

To be honest, I always assumed that one was checking for the availability of pypy.exe outside of the VirtualEnv.

There are two situations that need to be handled with respect to pypy/python.

1. the py(py|thon) environment where virtualenvwrapper-win itself is installed
2. the py(py|thon) version installed in a virtualenv.

In a few situations virtualenvwrapper-win uses py(py|thon) to execute commands that are unruly in .bat. Great care is taken so the Python code used is universal (can be ran on all supported Python versions). Up until now the python.exe used is whichever is found first on the path. It can be either of case 1 or 2 above, but since the Python code to be run is universal it hasn't mattered.

Apparently it is possible to run post-install code (re. checking for pypy from the outside)[1], but that only solves half the problem.

Regarding the escaping vars, I was reluctant to use SETLOCAL as I expected things to break then.

Yes, stay away from setlocal whenever possible. Using a name that is unique and unsetting it at the end is preferrable.

How about using some sort of preprocessor to plug things together?

That is certainly a possibility, and one that I've contemplated a couple of times. The natural choice for preprocessor would be Jinja2 if you're interested in going this route. It would also require an extra step during the build/publish(/test?) phase.

For now, I will add the bullet to CHANGELOG.rst and look into the other issues as I have time.

Excellent. The only thing that's coming from me in the near/medium future is a full hook implementation, but it shouldn't interfere with this PR.

[1] https://stackoverflow.com/a/36902139/75103

[wamserma]

As I've moved to greener pastures (mostly non-Windows) I'm abandoning this PR, releasing it to the public domain.
If someone cares, pick it up. Otherwise it may rest in peace.