Idea: expose a psutil.tests.support module

[giampaolo]

Despite psutil.tests test utilities are currently not public nor documented, they do get installed with psutil, and they are accessible as:

from psutil.tests import something

There's a ton of useful stuff in there, especially for dealing with processes (reap_children(), get_test_subprocess(), create_zombie_proc(), pyrun() and others), so it may make sense to document the most "stable" functions, and state that their APIs may be subject to change, similarly to cPython's test.support module.

[w0rmr1d3r]

Hi @giampaolo , I was about to open an issue regarding the tests being installed and exposed. Should they be exposed? For what you say, they include useful stuff. It would be great to have that stuff as part of this package but remove the tests from the installation?

Thank you for such a great project!

[giampaolo]

Hi, yes, I still think there is value in publicly exposing the test API.

It would be great to have that stuff as part of this package but remove the tests from the installation?

I think there is value in installing tests, regardless of whether we officially expose the test API. Reason: you can do python3 -m psutil.tests and check your psutil installation.

[w0rmr1d3r]

Hello 👋 , Do you mean, to check which version of psutil is installed? If so, what about checking it with pip list? Or exposing a version, similar to what I'm doing here? https://github.com/w0rmr1d3r/cloner/blob/master/cloner/__version__.py

[giampaolo]

No, I mean that after you install psutil via pip:

python3 -m pip install psutil

...you can run tests with:

python3 -m psutil.tests

This is a way to quickly check psutil installation without having to download the source code, do git clone ... etc.

[w0rmr1d3r]

Indeed! It's way faster and even easier, no setup "required". However, that code will be within other projects/packages that may not need the tests. And is code that might be running in production services.

What about having an easier setup for this project? That would remove the need to include tests in the package, wouldn't it?

[giampaolo]

Mmm.... I am afraid there is no blessed "standard" here. The bottom line is that some package maintainers decide to include tests in the package tarball/wheel, others do not. Since there is no standard, it seems tools also do not provide a way to exclude tests during installation (e.g. something like pip install --exclude-tests psutil). Googling for "pip install exclude tests" also didn't help.

I understand the "I don't want tests in a production env" argument, but to me this seems a problem more related to tooling (pip & co.) and/or lack of blessed standards rather than psutil itself.

Assuming tools provide no way to toggle the addition of tests during installation (as it seems), I think there is more value for psutil to include tests by default rather than not, mostly because on a prod env you can simply choose NOT to run tests.

[w0rmr1d3r]

Indeed, according to the documentation: A source distribution contains enough to install the package from source in an end user’s Python environment. As such, it needs the package source, and may also include tests and documentation. [...] Ref. https://packaging.python.org/en/latest/flow/#the-source-distribution-sdist

Tests and documentation may also be included in the package. Hence, there is no harm on adding them.

However, I wonder, what's the value of either running or having unit tests in the production environment? Of the +250k dependents and over the >12M downloads last week (congrats on both 🚀 ), how many of them needed the tests to be installed?

In any case, tools do not include the tests in the package by default when tests are done in a folder outside the source code. That is, in the root of the project/repo, a folder for the source code (the package) and different folder for the tests. Example: https://realpython.com/pypi-publish-python-package/#create-a-small-python-package

The initial debate still remains: if possible, to extract the useful stuff from tests and move it as part of the package and remove the tests from the package itself.