| Summary: | sys-apps/portage: enable DeprecationWarning message by default where appropriate | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Since DeprecationWarning messages are silent by default, they're not very effective for warning about pending removal. So, we should probably enable some of these messages by default as discussed in #gentoo-portage: > <[Arfrever]> Maybe also pass module="portage\..*" to warnings.filterwarnings > <[Arfrever]> So warnings.filterwarnings("default", category=DeprecationWarning, module="portage\..*") would enable only DeprecationWarnings originating from portage modules. > <[Arfrever]> zmedico: You can add above call somewhere in portage/__init__.py if you want :) . > <zmedico> [Arfrever]: are disadvantages to this? sounds like maybe a good idea. > <[Arfrever]> I have not noticed disadvantages. > <[Arfrever]> (I locally have most warnings enabled by PYTHONWARNINGS environment variable.) > <[Arfrever]> zmedico: If warnings.filterwarnings() was called inside Portage, then users would not be able to override its effect :) . > <[Arfrever]> Priority from highest to lowest: warnings.filterwarnings(), -W option, ${PYTHONWARNINGS}, internal defaults