Cannot be run using python -m

[jayvdb]

$ python3 -m green tests.tool_tests.TestArgSpec
/usr/bin/python3: No module named green.__main__; 'green' is a package and cannot be directly executed

[CleanCut]

You need to specify the module that actually handles command-line processing:

$ python3 -m green.cmdline ...

[jayvdb]

It would be good to include documentation of this. Thanks.

[e3krisztian]

@jayvdb I run some stuff like this myself, though not green I am curious what is your use case.

[jayvdb]

Currently I am testing using green on various versions of Python 2 & 3 to determine what blockers exist for adopting it. I could set up virtualenv's (and for automated testing we'll be using tox.), but for quick use it is easier to call a specific version of /usr/bin/pythonX.Y -m green....

[CleanCut]

@jayvdb Just in case you find it useful, you should be aware that green always install three binaries:

green
greenX
greenX.Y

When green is installed in multiple system python versions, green gets overwritten (last one installed wins).

When green is installed in multiple system python versions of the same major version X, then greenX gets overwritten.

If you install green in multiple system python versions, which each have a distinct major/minor combo, then you have the option of using the greenX.Y commands, since they won't have been overwritten. For example, you could install green under Python 2.7.9, 3.4.2, and 3.5.0, and use green2.7, green3.4, and green3.5.

[jayvdb]

Ya, but IMO these X and X.Y suffixes for tools are only good for simple usage, and becomes a problem with complex situations.
See https://github.com/pypa/pip/issues/3164

Invoking a specific binary is much safer and easier to keep as a consistent pattern that always works (except for Python 2.6, but hopefully we all need to use that less as time goes on.)

[CleanCut]

Included in 2.1.0