Moving away from batch scripts

[fuzzmz]

Writing this as a thought stemming from PR #71.

It looks to me that batch as a language has a lot of issues cleanly dealing with the complexities of multiple (and unknown) arguments, as well as it's weirder syntax and lack of options for complex testing suites.

The main advantage I see in batch for this project is that it can be natively executed on Windows, but does this one benefit outweigh the downsides?

What if the project would transition to a compiled language (C/Go/whatever) which would allow us to keep the contained execution intact (no dependencies needed) but also to more easily extend and develop this project?

[thebjorn]

.bat files are required for the same reason that shell functions are required in the original virtualenvwrapper: we need to change the running environment of the current process and there's no way to do that from a sub-process (cf. https://virtualenvwrapper.readthedocs.io/en/latest/design.html)

You are correct that .bat programming is horrendously tedious. The absence of a debugger (or line numbers in error messages) is very frustrating.

If we're to consider other languages (than .bat), the only natural choice would be Python. It would have to be a Python dialect that is executable by both Py2 and Py3.

The hook implementation of the virtualenvwrapper mother project involves executing the output of Python scripts, i.e. similar to:

set _tmpfile=%tmp%\tmpfile%random%.bat
python -c "print 'set ""MYVAR=42""'" > %_tmpfile%
call %_tmpfile%
del %_tmpfile%

to get the convenience of writing hooks in Python and still be able to change the current process' environment. I would see this as a viable option for issues that are notoriously difficult in .bat (like argument parsing).

[thebjorn]

Python also ships with a tcl interpreter...: https://stackoverflow.com/questions/2519532/example-for-accessing-tcl-functions-from-python

:-)

[xmedeko]

Some command has to be in .bat (or .cmd), as @thebjorn has mentioned, especially the workon command. While many others do not need to be .bat. If moving to Python, I vote for a simple command interface. E.g. venv mkproject instead of mkproject. (The Python argparse has a support for that as add_subparsers). I know it's not compatible with the original virtualenvwrapper, but IMO it would be nice even if the original project would move to this interface and some code could be shared.

[thebjorn]

@xmedeko I see how such an interface would be more in line with current developer expectations (since "all" other tools do this: svn/git/django/amazon). Writing in Python might not be as easy as you think though, since the system-installed Python could be any version at all. You can't just assume you have argparse (new in Python 2.7). optparse arrived in Python 2.3, but is deprecated in Py3. There's always getopt ;-)

If you want to work on a simple command interface I would suggest creating a separate project that implements this interface (perhaps by using https://github.com/pyinvoke/invoke as a layer on top of virtualenvwrapper and virtualenvwrapper-win). I think there would need to be some hands-on experience, and some design iterations, to develop such an interface that is better done in a separate project.

[xmedeko]

@thebjorn Thanks for pointing to the Pyinvoke, it may be all what I need. I'll try that. Note: most of Python tools and libs supports Python 2.7 and 3.4+ nowadays. I think you do not need to worry about Python pre-2.7 versions.

[thebjorn]

@xmedeko you're right, most python tools/libs support Py2.7/3.4+, but that is not the issue. The issue is what version of Python is installed as the global Python on the machine where virtualevnwrapper-win should run. That could very well be 2.4 (which we're supporting according to our setup.py file) if your company has legacy software that needs that version. It's important that virtualenvwrapper-win will run even then so those developers can create virtual environments with newer Pythons for their projects. Backwards compatibility can be a serious pain, but it's still important ;-)

[madig]

How about ditching cmd.exe (eww!!) and moving to PowerShell? It's what Microsoft wants and 6.x is cross-platform and good.

[xmedeko]

Most of scripts is possible to use in PS now. Only workon is problem. Current virtualenv has support for PS - it makes activate.ps1. IMHO it would be enough to make workon.ps1 which would call activate.ps1. Then virtualenvwrapper-win may be for both - cmd and PS, too.

[thebjorn]

@madig It would be nice to have a debugger. I'll probably end up getting the $99 Take Command software https://jpsoft.com/ just for their debugger.. I feel old now, I bought a license for 4dos in 1990... ;-)

Doing a full rewrite is definitely out of scope, but maybe someone can use this code as a starting point for virtualevnwrapper-powershell..?

ps: I didn't think ps v6.x ran on the windows versions we're supposed to support -- check the README.rst file ;-D

@xmedeko Well, it's not actually true that most of the scripts work in PS. I haven't ran the test suite, but from cursory checking I can see that

Doesn't work	works
cdproject	mkvirtualenv (probably not all flags)
cdsitepackages	lsvirtualenv
cdvirtualenv	addtovirtualenv
workon	lssitepackages
mkproject	virtualenvwrapper
rmvirtualenv

mkproject might look like it works, but it fails to change directory at a crucial point and makes a real mess. workon

[xmedeko]

There already is virtualenvwrapper-powershell but seems unmaintained and has lot of issues. Disclaimer: I use cmd (with clink) mostly, so I do not need the virtualenvwrapper-powershell

[DanielAtKrypton]

The workaround I am using to be able to work with Powershell is as follows:

Basically the idea is to manually run activate instead of activate.bat.