-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"tox -p all" to noise for extern contributors #756
Comments
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.
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? |
The simple thing to do would be to ask the developers to only run 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. |
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:
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. |
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. |
The contributors docu mention the use of
tox -p all
on the contributors local machine before opening a PR.The output is nearly useless because it is to noisy. So much work into unit tests and tox...
Make it short and clear. It is waste of time, ressources, energey/CO2 if users are not able to understand or even read that output.
A site problem is that it is unclear how to log the whole output to a text file. Does tox have an option for that? Piping stderr and stdout on shell should not be an option for regular users.
I really care for pydoctor. That is why I am so stuborn. 😃 I am also member of a maintenance team of a damn old Python GUI application. We are the third generation. The code smells a lot is nearly untested and untestable and also nothing is documented. But we took the challenge to clear up things, writing documentation and attract more contributors to the project.
Output like this does not help contributors and not you. The effect is the opposite: Driving contributors away and wasting resources (and nerves) of the maintainer and burning him out on the long run. I try to keep you healthy. 😆 ❤️
The text was updated successfully, but these errors were encountered: