Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Sep 2018 09:54:07 +0000
From:      bugzilla-noreply@freebsd.org
To:        python@FreeBSD.org
Subject:   [Bug 231555] Mk/Uses/python.mk: Add USE_PYTHON=pytest
Message-ID:  <bug-231555-21822-Mz34X13L0T@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-231555-21822@https.bugs.freebsd.org/bugzilla/>
References:  <bug-231555-21822@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231555

Kubilay Kocak <koobs@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |feature

--- Comment #3 from Kubilay Kocak <koobs@FreeBSD.org> ---
I'd like to see something like this leverage/extend the test framework bits=
 if
necessary to achieve what we want, to make it usable for cases other than j=
ust
pytest (nosetests, unittest, whatever). python.mk could then setup/wrap pyt=
hon
specific test scenarios, using generic TEST_* (TEST_COMMAND/TEST_CMD_ARGS, =
etc)
variables wherever possible.

I see most of the value created in leveraging/extending the test framework,
than is obtained from removing the need for TEST_DEPENDS and not needing to
specify a test target.

Test invocations are *notoriously* non-standard in the Python world (grante=
d,
python -m pytest 'is' a common one), with various permutations of a
env/commands/args combination necessary to get it just right.

Further, its very commonly the case that pytest along is not a
standalone/sufficient dependency by itself, and having them split implicitl=
y in
the framework and explicitly in the port is not particularly desirable.

This idea has been an open task [1] for the Python team for a while, looking
for at least a *minimally* considered/designed schema to support a pluralit=
y of
test execution needs, rather than just added on an adhoc basic, and hopeful=
ly
one that could be leveraged to the benefit of other softwares/language stac=
ks
in the ports tree.

Perhaps a good place to start would be to take stock of the existing test
methods for existing python ports and see what scheme we can come up with to
support the 'major classes' of test execution methods.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231555-21822-Mz34X13L0T>