-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving away from batch scripts #81
Comments
You are correct that If we're to consider other languages (than The hook implementation of the virtualenvwrapper mother project involves executing the output of Python scripts, i.e. similar to:
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 |
Python also ships with a tcl interpreter...: https://stackoverflow.com/questions/2519532/example-for-accessing-tcl-functions-from-python :-) |
Some command has to be in |
@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). 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. |
@thebjorn Thanks for pointing to the Pyinvoke, it may be all what I need. I'll try that. |
@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 |
How about ditching cmd.exe (eww!!) and moving to PowerShell? It's what Microsoft wants and 6.x is cross-platform and good. |
Most of scripts is possible to use in PS now. Only |
@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
|
There already is virtualenvwrapper-powershell but seems unmaintained and has lot of issues. |
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?
The text was updated successfully, but these errors were encountered: