I have trouble using third party plugins in my frozen program and discovered
that other people have experienced it as well:
https://mail.python.org/pipermail//pytest-dev/2015-June/003015.html
The problem is that the mechanism for plugin discovery used by pytest
(setupttools entry points) doesn't work with frozen executables so pytest
can't find any plugins. The solution seems to be to import the third party
plugins explicitly as shown here:
https://mail.python.org/pipermail//pytest-dev/2015-June/003018.html
This is not mentioned anywhere in the documentaion.
* Changed "index" to be more similar to the README (#1708).
* Fixes numerous issues like missing documents, syntax errors, etc (#1829, #432).
* Mention all docs in "contents.rst" so it's easier for users to locate (#1112).
* Add doc generation and checking to Travis and AppVeyor, to avoid re-introducing errors.
Fixes#432, Fixes#1112, Fixes#1708, Fixes#1829
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.
cx_freeze doesn't seem to be very well supported in Python 3.5.
Using pyinstaller instead and rename environment to "freeze" which
is a more generic term for freezing python code into standalone
executables.
Fix#1769
As per their email ‘Changes to project subdomains’:
> Starting today, Read the Docs will start hosting projects from subdomains on the domain readthedocs.io, instead of on readthedocs.org. This change addresses some security concerns around site cookies while hosting user generated data on the same domain as our dashboard.
Test Plan: Manually visited all the links I’ve modified. One was not modified - `http://media.readthedocs.org/epub/pytest/latest/pytest.epub` - since it doesn't work on `readthedocs.io`.
While this leads to slightly more complicated user code for the common
case (checking if the exception is of a given type) it's easier to
implement and more flexible.
When __tracebackhide__ gets set to an exception type or list/tuple of
exception types, only those exceptions get filtered, while the full
traceback is shown if another exception (e.g. a bug in a assertion
helper) happens.
Since 'py.test --help' shows --full-trace as an option (and not --fulltrace)
even though both forms are accepted I assume --full-trace is the preferred form
and should therefore be used in the documentation.