i'm packaging python-daemon for Guix. i have some experience with Python, the language, but not much with the ecosystem.
with that in mind:
the Guix python build system and builder daemon runs the tests using python3 -m setup test, which leads to some failures (test_exception_instance, test_exception_types, see https://pagure.io/python-daemon/issue/84 for the full output).
python3 -m setup test
test_exception_instance
test_exception_types
i assume it is because it runs some tests that were not meant to be run as standalone tests?
it's rather complicated to make make test (the preferred way to run the test suite) work in the guix build sandbox. it requires stuff like creating/patching a custom build backend to avoid pip trying to download dependencies.
make test
would it be hard (or wrong? or inappropriate?) to make python3 -m setup test work?
the Guix python build system and builder daemon runs the tests using python3 -m setup test
Step one is to end that; the Python ecosystem has been gradually deprecating the 'setup.py' program, and it is on its way out now.
The Python people in the Guix community likely are well aware of this, as it has been well advertised for many years. I don't know the Guix distribution but I expect they have allowance for avoiding the use of 'setup.py' entirely, since that will be increasingly necessary.
Which leaves us with the issue of running the test suite in this package. Currently it's done with make test, but as you rightly point out, that attempts to download dependency packages if they are not installed.
The package declares its dependency packages, and that includes the optional 'test' dependencies. So those can be installed separately, before attempting to run the test suite:
$ python3 -m pip install .[test]
What does Guix normally do to ensure dependency packages are installed for offline tests?
the Python ecosystem has been gradually deprecating the 'setup.py' program, and it is on its way out now.
I have opened issue 87 to declare this and track it for resolution.
You're right, this describes a separate issue. I have created issue 86 to describe and track this.
With the migration to 'changelog-chug' for interrogating the Change Log at build time, merged to the 'main' branch, this issue is now resolved.
Metadata Update from @bignose: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)