Run python check before releasing

[mauritsvanrees]

We can run python setup.py check, maybe with some options. Among others, this checks the long description. We have the longtest command for this too, but not everyone uses it or remembers to run it.

See plone/plone.recipe.codeanalysis#64

Probably we should do this in the prerelease phase.

[reinout]

What's the relationship with our brand spanking new 'readme' package check? Isn't that a better checker?

[mauritsvanrees]

That is exactly the one I mean. Or I think I do. It seems distutils has a check command and readme enhances it.

[do3cc]

I think this was implemented already, no?

[mauritsvanrees]

No. zest.releaser has had its own longtest command for a long time, but we are not calling it automatically before a release.

[mauritsvanrees]

I would like to pick this up in the near future, so some notes.

It seems fine to at least call python setup.py check --metadata --strict.

There is also python setup.py check --restructuredtext to check the readme, but that silently does nothing when docutils is not installed. In that case, calling it with --strict will exit with an error.

But the ReStructuredText checking is apparently deprecated. With a new enough Python, or maybe setuptools, I get:

$ bin/python setup.py check --metadata --restructuredtext --strict 
running check
warning: Check: This command has been deprecated. Use `twine check` instead: 
https://packaging.python.org/guides/making-a-pypi-friendly-readme#validating-restructuredtext-markup
The project's long description is valid RST.

(Clickable link.)

So we can call twine check dist/* when we have twine 1.12.0 or higher (1.13.0 is latest). Of course then we would need to call twine on the command line, which could theoretically be a different version on the os PATH than on sys.path. But we can just report an error and ask the user if he wants to continue.
I just now realized that twine check needs to be run on the distribution files, so this is easier done during release, but we want it during prerelease. So some tricks may need to be involved.

Calling longtest could then be easier. Or if available, we can call restview --long-description, which in essence is what twine check is doing anyway.
Maybe don't do this when setup.py/setup.cfg contains an optional long_description_content_type which is something other than 'text/x-rst'.
And with --no-input we should not open a browser.
And all or parts of these checks could be optional.

Actually, readme_renderer is the one that prints the above deprecation warning and advocates using twine check in its README. It used to create a restview script that you could call, with option --long-description to check the PyPI long description, which is exactly what we want, but that script is no longer created.
Ah, no: I am confused with a separate restview package that creates this script (and which by now uses readme_renderer internally). So we could use that.

And one final thing, which eases my mind about having to call twine or restview on the command line, and locating those commands: those two packages have been setup so you can call them with python -m twine and python -m restview --long-description. So we could basically call a command [sys.executable, '-m', 'restview'].

[reinout]

I'm dragging this one out of the archive. Perhaps our new way of using "build" instead of "setuptools" could make some of this easier. I haven't used it enough myself to really know atm.

[mauritsvanrees]

Maybe at the end of _project_builder_runner we could call:

execute_command(["twine", "check", "dist/*")