All is in the title, a lot of python tools (pip, gunicorn, virualenv, venv, ...) are having the same CLI behaviour whether they're called using the setuptools entrypoint, or called with their package's "main". The benefit of having both interfaces is that one can run the package even if he does not have his path setup correctly for a given virtualenv. I just need to know the python interpreter path, and can use libraries from there
If we run python -m honcho today, it prints: No module named honcho.__main__; 'honcho' is a package and cannot be directly executed
What I propose is that python -m honcho becomes equivalent to honcho, in a given environment.
If you are ok for this, I can handle implementation, which should be trivial (it's basically only creating a __main__.py file in honcho's package root and calling the same thing as does the setuptools entrypoint there).
All is in the title, a lot of python tools (pip, gunicorn, virualenv, venv, ...) are having the same CLI behaviour whether they're called using the setuptools entrypoint, or called with their package's "main". The benefit of having both interfaces is that one can run the package even if he does not have his path setup correctly for a given virtualenv. I just need to know the python interpreter path, and can use libraries from there
If we run
python -m honcho
today, it prints:No module named honcho.__main__; 'honcho' is a package and cannot be directly executed
What I propose is that
python -m honcho
becomes equivalent tohoncho
, in a given environment.If you are ok for this, I can handle implementation, which should be trivial (it's basically only creating a
__main__.py
file in honcho's package root and calling the same thing as does the setuptools entrypoint there).Let me know.