Why does a DeprecationWarning raised by a library never appear when you run your app?

### Warnings are not exceptions and not logging `warnings.warn(message, category)` reports a condition the program can survive: a call site that will stop working, a resource that was not closed, a construct whose meaning is about to change. Unlike `raise`, it returns and execution continues. Unlike a log call, it is routed by a filter chain rather than by a logger hierarchy, and by default it is written to `sys.stderr` by `warnings.showwarning`, with no configuration required. Every warning has a **category**, which is a class deriving from `Warning` (itself a subclass of `Exception`). The category is how the machinery decides who the message is for: - `UserWarning` — the default when you pass no category; a message for whoever is running this code. - `DeprecationWarning` — for *developers*: something this code calls will be removed. - `PendingDeprecationWarning` — the same, further out. - `FutureWarning` — for *end users*: behaviour will change under them. It is shown by default. - `RuntimeWarning`, `SyntaxWarning`, `ImportWarning`, `ResourceWarning`, `BytesWarning`, `EncodingWarning` (added in 3.10) — the interpreter's own categories. ### The filter chain `warnings.filters` is an ordered list of five-tuples: an action, a compiled regex matched against the message text, a category class, a regex matched against the *module* the warning is reported from, and a line number. A warning is checked against each entry in order and the **first** entry that matches wins; if nothing matches, the implicit `default` action applies. The actions are `error` (raise the category as an exception), `always` (print every time), `default` (print once per unique location), `module` (once per module), `once` (once per process for that message and category) and `ignore`. On a plain `python app.py` in 3.14 the list is, in order: `default` for `DeprecationWarning` in `__main__`, then `ignore` for `DeprecationWarning`, `PendingDeprecationWarning`, `ImportWarning` and `ResourceWarning` anywhere. Read top to bottom, that is the whole answer to the question. Your library's deprecation is reported from a module that is not `__main__`, so it falls through to the blanket `ignore` and disappears. The same `warn` call in the script you launched matches the first entry and prints. ### Why it is built that way Python 3.2 silenced `DeprecationWarning` by default because end users of applications were being shown messages they could do nothing about — the person running a program cannot fix a library's use of a deprecated API. That, predictably, meant developers never saw them either, and deprecations stayed unfixed until the removal broke everything. PEP 565, in Python 3.7, restored visibility exactly where the person who can act is likely to be looking: code in `__main__`. Libraries stayed quiet; scripts and REPL sessions started talking again. ### Making them visible on purpose Four levers, in rough order of scope: 1. **Command line**: `python -W default::DeprecationWarning app.py`. The spec is `action:message:category:module:lineno`, all fields optional. Multiple `-W` options are allowed and the last one given takes precedence, because each is inserted at the front of the filter list. 2. **Environment**: `PYTHONWARNINGS="default::DeprecationWarning"`, comma-separated for several specs — the way to configure a container or a CI job without touching the entry point. 3. **Development mode**: `-X dev` (or `PYTHONDEVMODE=1`) turns on the default filters, so `DeprecationWarning` and `ResourceWarning` become visible everywhere, along with other runtime checks. 4. **In process**: `warnings.simplefilter('default')` or `warnings.filterwarnings('error', category=DeprecationWarning, module=r'myapp\.')` from your application's entry point — never from library import code, which has no right to rewrite a process-wide policy. The common production pattern is to make deprecations fatal where they can be fixed and invisible where they cannot: `-W error::DeprecationWarning` in CI, plain defaults in production. A test runner that enables warnings for you is doing the same thing one layer up. ### The trap Because the `module` field is matched against the module the warning is *reported* from, and the reported location is chosen by the `stacklevel` argument, a library that warns with the default `stacklevel=1` attributes the warning to itself; one that sets `stacklevel=2` attributes it to its caller — which changes which filters match. A deprecation warned with `stacklevel=2` out of a library called directly from your script is reported from `__main__`, and therefore shows up under the shipped defaults. Two libraries can behave differently for exactly this reason.