Freeze docs: PyInstaller hook and wording
As discussed during the review, suggest in general to use PyInstaller and just mention pytest.freeze_includes() in less detail on how to actually use it, because it varies from tool to tool.
This commit is contained in:
parent
ed36d627e4
commit
ae9d3bf886
|
@ -699,8 +699,8 @@ and run it::
|
|||
You'll see that the fixture finalizers could use the precise reporting
|
||||
information.
|
||||
|
||||
Integrating pytest runner and PyInstaller
|
||||
-----------------------------------------
|
||||
Freezing pytest
|
||||
---------------
|
||||
|
||||
If you freeze your application using a tool like
|
||||
`PyInstaller <https://pyinstaller.readthedocs.io>`_
|
||||
|
@ -708,29 +708,21 @@ in order to distribute it to your end-users, it is a good idea to also package
|
|||
your test runner and run your tests using the frozen application. This way packaging
|
||||
errors such as dependencies not being included into the executable can be detected early
|
||||
while also allowing you to send test files to users so they can run them in their
|
||||
machines, which can be invaluable to obtain more information about a hard to reproduce bug.
|
||||
machines, which can be useful to obtain more information about a hard to reproduce bug.
|
||||
|
||||
Unfortunately ``PyInstaller`` can't discover them
|
||||
automatically because of ``pytest``'s use of dynamic module loading, so you
|
||||
must declare them explicitly by using ``pytest.freeze_includes()`` and an
|
||||
auxiliary script:
|
||||
Fortunately recent ``PyInstaller`` releases already have a custom hook
|
||||
for pytest, but if you are using another tool to freeze executables
|
||||
such as ``cx_freeze`` or ``py2exe``, you can use ``pytest.freeze_includes()``
|
||||
to obtain the full list of internal pytest modules. How to configure the tools
|
||||
to find the internal modules varies from tool to tool, however.
|
||||
|
||||
Instead of freezing the pytest runner as a separate executable, you can make
|
||||
your frozen program work as the pytest runner by some clever
|
||||
argument handling during program startup. This allows you to
|
||||
have a single executable, which is usually more convenient.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# contents of create_executable.py
|
||||
import pytest
|
||||
import subprocess
|
||||
|
||||
hidden = []
|
||||
for x in pytest.freeze_includes():
|
||||
hidden.extend(['--hidden-import', x])
|
||||
args = ['pyinstaller'] + hidden + ['runtests_script.py']
|
||||
subprocess.check_call(' '.join(args), shell=True)
|
||||
|
||||
If you don't want to ship a different executable just in order to run your tests,
|
||||
you can make your program check for a certain flag and pass control
|
||||
over to ``pytest`` instead. For example::
|
||||
|
||||
# contents of app_main.py
|
||||
import sys
|
||||
|
||||
|
@ -742,7 +734,7 @@ over to ``pytest`` instead. For example::
|
|||
# by your argument-parsing library of choice as usual
|
||||
...
|
||||
|
||||
This makes it convenient to execute your tests from within your frozen
|
||||
application, using standard ``py.test`` command-line options::
|
||||
This allows you to execute tests using the frozen
|
||||
application with standard ``py.test`` command-line options::
|
||||
|
||||
./app_main --pytest --verbose --tb=long --junitxml=results.xml test-suite/
|
||||
|
|
Loading…
Reference in New Issue