"tox -p all" to noise for extern contributors about pydoctor

[tristanlatr]

Tox is not a hard requirement for external users (see my last comment on #753), I agree it’s not clear in our documentation. But contributors can figure that out by reading the setup.cfg file. Though pytest will still be required.

The primer cannot be only run when preparing a release because it looses the point: which to catch regressions the fastest as possible. So that will be run on every PR.

I believe this is all a matter of documenting our tests infrastructure. So let me a week to draft a better contributors documentation. I’ll ask your review then.

[tristanlatr]

I don’t know what to say honestly. I’m really glad you care about pydoctor. But you have to stop being so judgmental. Let’s focus on actionable items, here your not suggesting anything.

Does tox have an option for that? Piping stderr and stdout on shell should not be an option for regular users.

I assume that tox have an option for that. And sorry to put it this way but developers should be able to handle simple stdout redirects. We are not regular users: I simply cannot vulgarize everything contributors needs to know. But I agree things could be streamlined a little bit.

Now what are the action points in your opinion?

[tristanlatr]

The simple thing to do would be to ask the developers to only run tox -e test locally and defer the rest of the tests to the ci. Then we briefly explain each ci step in our contribution docs.

Then we move all dependencies listing int the Setup.cfg file and eventually flush the tox requirements for external contributors. But that’s going to work only for the unit tests, other tests requires tox.

[buhtz]

My main problem is that tox is used. But as I stated before this is up to the maintainer to decide it. I am not enough into tox or into your project to build an objective opinion about the question if tox is really needed and useful here beside that it is just a fancy tool.

From my point of view as an extern contributor and the tasks I have to do, tox do not help. The tools and dependencies to use for an extern person should be as less as possible to keep the hurdle low. Contributors do not need a special thanks or applause but FOSS maintainers should be happy about every contribution they could get even if they are worse. The latter, handled a correct way, could be transformed into a healthy and productive relationship.

In short: IMHO maintainers should do a bit advertising and marketing when it comes to contributors to attract them, not driving them away and keeping them connected to the project.

So if you do not have a strong indication I would recommend to remove tox from the processes where extern contributors are involved. If you can not do this for good reasons you need to document it. The latter is because tox is not a regular and usual tool. Not everyone knows how to handle it. And contributors should not take the burden to read manuals of tools they won't use in their own workflows. Even "pytest" is not regular in that context. The unitest module is regular. Everything else is an extra and might increase the burden of contributors. That you use pytest-style tests should be part of the documentation. And that test code need to be documented better (as I stated in another issue) because pytest-tests are very hard to read because they hide to much and doing things implicit.

Tox and most of your CI jobs should not be removed but hidden from contributors. E.g. the primer thing could be done when you prepare a release. In my own project we do have a prepare-release-checklist where we run and activate stronger tests. It could be done/triggered in a manual way and do not need to be in a CI job.

Two options:

1. Remove/hide tox.
2. Document the use of tox for extern contributors and do it like you explain it to a 6 year old.

About redirecting on bash: Bash is for inter-machine/-process communication and not invented for humans. The machine need to attach to the human not the other way around. There are exceptions of course; using Emacs with evil-mode is a compromise (like in a marriage) between human and the machine. Redirecting stderr/stdout is a stupid job the machine should do and hide from myself. That is why I ask for something like a log option for tox.