No module named vex.__main__ - Windows
nebffa opened this issue · comments
On Python 3.4 when trying to run vex on Windows with python -m vex I get the error No module named vex.__main__; 'vex' is a package and cannot be directly executed.
This is because I'm running vex as a script which has no __main__ method. I can't run just vex from the command line because it's not on the path. I think it's something to do with the new venv in Python 3.4.
I know you have advice to add the vex script to the PATH environment, but I think most people just want things to be fully installed and ready to go when they do pip install vex. Do you have any good idea of how to go about that?
I read the other issues and it looks like you're looking for some help with supporting Windows. I'd be happy to help - it sounds like some of the Windows-related stuff could deal with some simplification.
I don't say this to be mean, but did you try following the instructions? Given what you've said, the most likely reason you can't just type 'vex' isn't a bug caused by interaction with venv, it's that you haven't done the necessary configuration.
The reason python -m vex doesn't work is that I intentionally did not write a main.py. It's easy, I just would rather people type 'vex' as designed instead of the longer 'python -m vex' (or C:\Python27\python -m vex, etc.) If I ever go to the python -m workaround it will be after exhausting all reasonable options. Linux and Mac users get to type 'vex' and so should Windows users (and in all cases it requires a small amount of configuration which is helpful for so many other tools and is part of a normal development environment setup). This is the normal pattern for all command-line utilities, IMO 'python -m' is designed for running things that should not pollute $PATH like demos, but vex is a command-line utility like any other and should be accessible in the normal way.
You can't get away from modifying %PATH% if you use command line tools on Windows, and Python packages can't safely do this for you. Even if we cover this up for vex with python -m or other methods so that people can temporarily avoid doing any configuration, that will still leave confused support requests from people who are interacting with other tools that need that configuration. Trying to avoid configuring a development environment is one of those things where we are saving a little effort up front at a cost of greater and recurring effort in the future.
I understand you prefer a workaround (via python -m). I think following instructions from the documentation is a reasonable solution. If the documentation on this is confusing or does not work for you then help me fix the documentation for others.
The other issue's problem with Windows is about infrastructure for vex developers to run tests on branches on an ad hoc basis as features are developed and bugs are fixed, so if you want to discuss that further over there then that's cool.
No response, closing