Introduce package_name/__main__.py

[Stefano Taschini]

The cookiecutter template defines a run-app script that can be used to run the app:

$ ./env/bin/run-app

or, if you have activated the virtualenv:

$ run-app

I suggest we introduce a package_name.__main__.py module, which would make it possible to run the app also as:

$ python -m package_name

or

$ ./env/bin/python -m package_name

The content of package_name.__main__.py could in practice replace run.py:

import morepath
from .app import App


def run():
    morepath.autosetup()
    morepath.run(App())

if __name__ == '__main__':
    run()

And the entry-point in setup.py would be changed accordingly.

[Denis Krienbühl]

I like this idea!

[Stefano Taschini]

Any additional feedback, @faassen, @henri-hulski ?

[Michael R. Bernstein]

I like this idea too. 👍

[Martijn Faassen]

I'm not a huge fan of __main__ as it seems to be a more limited version of entry points, but it is also simpler and what some people expect, and the entry point won't break, so +1.

[Henri Hulski]

I think I have no opinion. For me it's ok like it is now but this change doesn't really hurt.
Actually I didn't get really the point what is the sense of this change.

[Stefano Taschini]

@henri-hulski The point is to provide an alternative way to run the app. There are a few reasons why you might be disinclined to or prevented from running the app using the script generated by Setuptools:

• Name collision: your app might mount a second app defined in a separate cookie-cutter based project. Which run-app script will be the one in the scripts directory? A possible solution to this problem is obviously to introduce a namespace for the installed scripts: project1-run-app, project2-run-app. This might work in this case, but does not scale well with the number of scripts -- do you guys remember Git before version 1.6? with all the git-commit, git-status etc.? -- The next step is then to have just one script (like git) which takes care of dispatching to subcommands (like git commit, git status, etc.). In other words, the ultimate solution to prevent name collision is to have one (and only one) script with the same name as that of the package. You might as well use the package itself.
• Poor discoverability: Look in the bin directory of the buildout of Morepath. Without looking it up, could you tell me what package installed the longtest script? Your run-app script can easily get lost in the scripts directory of the Python environment, if you are using packages like zest.releaser which drop each a bunch of scripts in the same place. You can alleviate this problem if you add a namespace to the script, and … we fall back to the previous case.
• You might be developing on Windows: even without addressing the fact that Setuptools on Windows generates non-digitally-signed EXE files for entry-point scripts, people there are used to the fact that even in the case of pip the safest way to run it is as python.exe -m pip