add tox.ini and .travis.yml

[qwcode]

many people use tox and travis, right?

maybe this is "feature creep" for the point of this project, but I don't know.
I'm inclined to add it.

[pfmoore]

Makes sense if tox/travis is the recommended practice. We're getting very close to workflow recommendations here rather than simple packaging recommendations. I think it's needed, and in general I'm +1 on this, but we want to keep in mind what we're trying to cover at the same time.

See also my issue (to be added) about test layout...

[pfmoore]

You should probably add a short explanation of tox.ini/.travis.yml into the README as well.

[jcjf]

Would this get a bit out of hand if you then added docs (Sphinx). Is the goal to just educate on modern best practices for distutils/setuptools (what I was hoping to learn), or is the scope wider than that?

[pfmoore]

My original reason for creating this project was to have a template covering best practices, so testing, docs, etc. So on that basis, docs is definitely in scope. Whether that is still the case now that the project has been put under the pypa umbrella is less clear.

If docs and testing are in scope, then someone else will have to set up those parts. I don't know enough to do so.

If you just want to get going with a template, then it may be worth your while looking at cookiecutter - they have a couple of very comprehensive templates (too comprehensive for what I was trying to do, but that's a pretty fine distinction at times...)

[cjerdonek]

I'm a big fan and user of both tox and Travis, but for several reasons, I think it would be better for this particular project to lean more towards a "minimal" sample project that doesn't favor particular tools, etc.

I do think it's valuable to have sample projects that incorporate a lot more (doc toolchain, testing toolchain, etc), but I think it would be better for that to be in addition to a minimal project.

[Ivoz]

I think for 3rd party stuff, maybe telling people about it is good enough (even saying "look at what x and y have done!"), rather than personally needing to demonstrate everything.

[VelizarVESSELINOV]

👍 I'm for favorable a complete default project, including all the quality online aspects:

• CI like Travis, Circle, etc.
• static code analysis like Quantifiedcode, Codacy, etc.
• code coverage like Coveralls, Codecov, etc.
• documentation like Read the Docs, etc.
• license like MIT, BSD, etc. (Allow the project to be used as starting point for non-MIT licensed project #17)

After that how you manage all the possible combinations, if a user want to have a project that is licensed X, CI Y, etc. can be challenging.

One solution is to have several GitHub projects, single project with different branches or build a project template wizard that is creating the project with some user selected options.

[pfmoore]

If we include travis, we should probably also include appveyor, to encourage testing cross-platform.

[gene1wood]

This was completed in PR #37 . Is this issue clear to be closed?