Don't install test.framework package

[Flamefire]

This results in a top-level Python package called "test". As this isn't namespaced to easybuild it can cause issues with other Python packages and shouldn't be installed.

Additionally IMO it isn't useful to install the tests in the first place.

[boegel]

I agree that namespace-wise this isn't nice, but I think there's some value in includes the tests with the installation.

This is a "feature" for a long time now, see also https://docs.easybuild.io/unit-tests/#unit_tests_running

If we want to change this, we need some kind of migration path, for example change the namespace to easybuild.test.*, and make test.framework a wrapper that (in EasyBuild 5.x) just calls out to easybuild.test.framework and later (in EasyBuild 6.0+) produces a hard error and mentions that easybuild.test.framework should be used instead.
Likewise for easyblocks & easyconfigs, of course.

[Flamefire]

I agree that namespace-wise this isn't nice, but I think there's some value in includes the tests with the installation.

I'd say 99% of users do not need nor want the tests, even though they don't take much space

This is a "feature" for a long time now, see also docs.easybuild.io/unit-tests#unit_tests_running

From how I read it nothing there states that the unit tests are installed / part of the distribution package, only that there are unit tests, how to run them and that they are run on CI. And running the tests isn't something so important that we need a deprecation period if any process is easily adapted. We can just update the documentation.

Some guides (1 & [2] use a tests folder (plural) in the root. Others use a namespaced tests package, e.g. the PYPA group (pip, setuptools, ...)

So I'd say we go with the latter: easybuild.<pkg>.tests (for framework, easyconfigs, easyblocks)
Or have them collected in one folder in the installation: easybuild.tests.<pkg>. That would be similar to the current python -m test.easyblocks.suite --> python -m easybuild.tests.easyblocks.suite