Integrate travis

[ghost]

Now that we have tests via tox, we can integrate Travis

[igeligel]

It would be good to have some requirements here:

• setup Travis so it can be used
• all relevant users have access to the system
• configuration is created
• tests are automatically run when a commit is pushed
• (publish package automatically when the version has changed)

What do you think?

[ghost]

"configuration is created" should be:

The .travis.yml file should do the following:

• Provision 3 different database engines
• Copy the .sample settings to file without .sample
• Invoke tox after provisioning

Will have to see about when to run tests.

I don't believe in automatic publishing, packaging maybe, but not publishing, so I can test the package locally and if there's an oversight can either move tags, or bump again.
But don't make a package hit PyPy for no reason - downstream are stuck with it for at least an hour.

Otherwise, yes.

[igeligel]

You can have different build stages to differentiate between environments: https://docs.travis-ci.com/user/build-stages/

I don't believe in automatic publishing

It just gives you advantages if you have good tests in place. The pipeline could run a diff on the version in the setup.py and then automatically bundle and publish. Clients can lock the version if they want. It just improves the developer experience for this package a lot. Also check out the principle: Release early, release often: https://en.wikipedia.org/wiki/Release_early,_release_often

If you need to test it locally to find issues, you are not fighting the root problem here which is missing tests then.

[ghost]

If you need to test it locally to find issues, you are not fighting the root problem here which is missing tests then.

You're assuming the reason to reroll a release are based on code. I'm not. If I can clean up human language, add emphasis to certain passages or highlight new features in release notes, I see it as improvement of that release. And if you keep that "for next time", you know it's not going to happen.
Anyway, let's see if releasing becomes a flawless endavour in the future and then we can add it to possiblities. Right now, I don't see it as a requirement for 0.5 (See roadmap).

[igeligel]

releases are based on code [...] I'm not

If you follow semantic versioning, which you should, it is.

Every bugfix is an increase in the patch version, every non-breaking feature is a minor version upgrade, every breaking change is a major version. Combining this with git tagging gives you the opportunity to easily version your package and make it available really easy.

Also see how easy it is: https://circleci.com/blog/continuously-deploying-python-packages-to-pypi-with-circleci/ (using circle ci but should be similar to travis).

Really, if people do not push for semver and automatic releases then humans will make mistakes, which is granted. In the Node.js community this is a bigger problem because you rely more on external packages and solutions got created like https://github.com/semantic-release/semantic-release#readme to actually release code automatically. If you have some time lookup the resources here https://semantic-release.gitbook.io/semantic-release/support/resources and then you might understand why this topic should be important.

[ghost]

Please don't assume lack of knowledge on my part, just because you don't agree with a well-informed choice.