Some ideas

[Henri Hulski]

I just tried morepath-cookiecutter. Really nice stuff!

Just some minor ideas:

• Maybe we should use "@id" instead of "url" in the json response in tune with the json-ld syntax.
• Adding global-exclude *.pyo to MANIFEST.in as in some systems they get created instead of *.pyc
• For me it's a little strange to install the virtualenv directly in the project folder as you propose in README.md. I always use a subfolder (venv or env). Otherways the project get cluttered with folders from the virtualenv.

Beside this it's really a good starting point.

[Denis Krienbühl]

Glad you like it!

Maybe we should use "@id" instead of "url" in the json response in tune with the json-ld syntax.

Good idea. Done!

Adding global-exclude *.pyo to MANIFEST.in as in some systems they get created instead of *.pyc

That makes sense, done.

For me it's a little strange to install the virtualenv directly in the project folder as you propose in README.md. I always use a subfolder (venv or env). Otherways the project get cluttered with folders from the virtualenv.

Honestly, I wasn't even aware this was possible. I have been using virtualenvwrapper for years though, so I lost touch with plain virtualenv.

Anyway, I did that as well and I like the result.

Thank you for your feedback!

[Henri Hulski]

Anyway, I did that as well and I like the result.

If you activate the virtualenv you can use the commands in env/bin/ directly.
No need for env/bin/pip, just use pip and the same with the other commands.

[Denis Krienbühl]

If you activate the virtualenv you can use the commands in env/bin/ directly.
No need for env/bin/pip, just use pip and the same with the other commands.

I am aware of that. I like to refer to the whole path for beginners because it ensures that the correct binary is used in any case. It's easy to miss something during a tutorial or to have the PATH somehow jumbled up and refer to the wrong binary.

[Henri Hulski]

Yeah I agree. Like this it's more transparent.

[Henri Hulski]

Thanks for your feedback. Sorry it took me a while to get back to you:

If we want flake8 to parse we should add a # flake8: noqa line on top of __index__.py.
Otherwise we get a 'App' imported but unused error.

I prefer to use __all__ = ['App'] to achieve the same thing. You are right though, we should avoid PEP8 errors.

Do reach coverage we should ignore run.run() as it make no sense to test it.
We can add # pragma: no cover after def run():.

Since coverage is not included in the example package I would rather not add any directives for it. There might be other tools the end-user uses which use different directives.

In setup.py there is the line: packages=find_packages(exclude=['ez_setup']).
I actually don't understand exclude=['ez_setup'].

That's a good question. I used my company's python template as a starting point and I think we've been using this for a few years. I think it's no longer needed, so I'll remove it.

Just a question: The namespace_packages is used only if there is a dot in the package name.
So if there is no dot it doesn't harm?

It shouldn't. The template should work with both namespaced and plain packages.

Why you use an empty config.py instead of __index__.py in the test directory?

Py.test recommends you don't use __init__.py. See https://pytest.org/latest/goodpractices.html#choosing-a-test-layout-import-rules. The conftest.py file on the other hand is the default test config file for py.test. Since it's empty I'll remove it though.

• I would not exclude *.mo files from distribution in .gitignore and MANIFEST.in.
  I always include them in my distributions, so the users have not to compile them themselves. I will remove the exclude rule anyhow though, since it's not our decision to make.

Actually, since the byteorder of mo files is machine-specific, they should not be included in distributions. You probably won't run into problems in real life, but it is correct to exclude those files. See https://www.gnu.org/software/gettext/manual/html_node/MO-Files.html

• I think as we moved the virtual environment to env, in setup.cfg we can just use
  norecursedirs = env.

Good point!

I think it would be good to clean up .gitignore a bit.
Now we also don't need the directories from virtualenv as we have them in env.
Also we don't need the buildout stuff.
And I would not include something which is not related with our setup like Django and C stuff.
Everybody can add what he need (for me e.g. Javascript related).

I'll use your .gitignore!

[Martijn Faassen]

The recommendation for py.test says that inlined tests (which we use) can use an __init__.py. I think __init__.py allows the from .. import blah construct whereas without __init__.py that doesn't work, but I'm not sure.

[Denis Krienbühl]

The recommendation for py.test says that inlined tests (which we use) can use an init.py. I think init.py allows the from .. import blah construct whereas without init.py that doesn't work, but I'm not sure.

I personally always leave out the __init__.py file. That ensures that my tests are never accidentally imported by other parts of the code (or other tools scanning my directories). However we do it in Morepath proper, I think it's good practice to not use __init__.py in projects which use Morepath.

[Martijn Faassen]

No problem for me. This issue is rather drifting, can we spin off more concrete issues and close this one?

[Denis Krienbühl]

Agreed.

[Henri Hulski]

@href
Just recover your answer here.
Actually you didn't answered, but edited my answer so I found it only by accident. 😉

I just gonna adopt some samples to the cookiecutter template so had a look here.
For me it seems now everything fine. 😄

Thanks for fixing it.