Add requirements-test.txt

[drew2a]

The problem

We have two environments:

• Pure Tribler
• Test Tribler

Pure Tribler installs only necessary dependencies, they located in src/requirements.txt.

But there is no documentation and no requirements.txt for the Test Tribler.

Solution

I've added src/requirements-dev.txt and small instruction on how to run tests.

Maybe requirements-dev.txt is a bad name, and better to use requirements-test.txt.

What do you think?

[kozlovsky]

If these requirements are for tests specifically, I like the name requirements-test.txt better. But what about things like pre-commit, maybe it should also be specified? Then it probably should be requirements-dev.txt.

Maybe a good idea to specify all necessary tools for new developers to easily join the project.

[qstokkink]

I'm impartial towards -test.txt or -dev.txt, both are used by other projects.

I would like to see the documentation in the docs/ folder though, fragmented documentation strewn about in README.md files in src subdirectories is very hard to maintain.

Nit: export PYTHONPATH=${PYTHONPATH}:echo {pyipv8,tribler-common,tribler-core,tribler-gui} | tr " " : does not work on Windows, we should make a Python script to launch the tests in an OS-independent manner.

[devos50]

Note that I added run_tests.sh and run_tests.bat in the tribler/src directory recently.

[drew2a]

@kozlovsky I think it's a common courtesy to have such documentation in a project. I'm not sure we are the best persons for doing this, but we can try to write it.

@qstokkink good to know you are worried about documentation maintaining.

First of all: the most valuable part of this PR is requirements-test.txt, not documentation.

Next, I'm also worried about maintaining the documentation and I'd like to see the documentation changed every time the code changed. I understand that this is difficult. How to do this is less painful is to keep the documentation as close to the code as possible.

Note: current project documentation is quite outdated and fragmented.

[qstokkink]

@qstokkink good to know you are worried about documentation maintaining.
[...]
Next, I'm also worried about maintaining the documentation and I'd like to see the documentation changed every time the code changed. I understand that this is difficult. How to do this is less painful is to keep the documentation as close to the code as possible.

Note: current project documentation is quite outdated and fragmented.

Historically, nobody gives a poop about the documentation. If you can somehow turn this around, I am all ears. Right now, I just perform a check-up manually every so often (apparently yearly): #2719, #3770, #3784, #4656.

[drew2a]

@qstokkink we can accept our Definition of Done.
One item in DoD will be "All changes are reflected in the documentation".

Looks like a good topic for further discussion :)

Examples:

• https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done
• https://github.com/Privatix/dappctrl/blob/master/CONTRIBUTING.md#pull-request-process
• https://github.com/arvidn/libtorrent/blob/RC_2_0/CONTRIBUTING.rst#pull-request-checklist

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[qstokkink]

@drew2a good point, we should probably mention the documentation here somewhere (at least): https://github.com/Tribler/tribler/blob/devel/doc/contributing.rst#pull-requests.

From your examples, this is the only one that I would actually expect developers to take the time to read: https://github.com/Privatix/dappctrl/blob/master/CONTRIBUTING.md#pull-request-process. It's categorized and concise. It would be cool if we could converge to something similar.