%global _empty_manifest_terminate_build 0 Name: python-flake8-logging-format Version: 0.9.0 Release: 1 Summary: please add a summary manually as the author left a blank one License: Apache License 2.0 URL: https://github.com/globality-corp/flake8-logging-format Source0: https://mirrors.nju.edu.cn/pypi/web/packages/b2/ef/29872deec77dcab8101b4d4571d1e637d173814af5eb73655f669747c6eb/flake8-logging-format-0.9.0.tar.gz BuildArch: noarch %description # flake8-logging-format Flake8 extension to validate (lack of) logging format strings ## What's This? Python [logging](https://docs.python.org/3/library/logging.html#logging.Logger.debug) supports a special `extra` keyword for passing a dictionary of user-defined attributes to include in a logging event. One way to ensure consistency and rigor in logging is to **always** use `extra` to pass non-constant data and, therefore, to **never** use format strings, concatenation, or other similar techniques to construct a log string. In other words, do this: ```python logger.info( "Hello {world}", extra=dict( world="Earth" ) ) ``` Instead of: ```python logger.info( "Hello {world}".format(world=Earth) ) ``` ## Extra Whitelist As a further level of rigor, we can enforce that `extra` dictionaries only use keys from a well-known whitelist. Usage: ```bash flake8 --enable-extra-whitelist ``` The built-in `Whitelist` supports plugins using `entry_points` with a key of `"logging.extra.whitelist"`. Each registered entry point must be a callable that returns an iterable of string. In some cases you may want to log sensitive data only in debugging scenarios. This is supported in 2 ways: 1. We do not check the logging.extra.whitelist for lines logged at the `debug` level 2. You may also prefix a keyword with 'debug\_' and log it at another level. You can safely assume these will be filtered out of shipped logs. ## Violations Detected - `G001` Logging statements should not use `string.format()` for their first argument - `G002` Logging statements should not use `%` formatting for their first argument - `G003` Logging statements should not use `+` concatenation for their first argument - `G004` Logging statements should not use `f"..."` for their first argument (only in Python 3.6+) - `G010` Logging statements should not use `warn` (use `warning` instead) - `G100` Logging statements should not use `extra` arguments unless whitelisted - `G101` Logging statement should not use `extra` arguments that clash with LogRecord fields - `G200` Logging statements should not include the exception in logged string (use `exception` or `exc_info=True`) - `G201` Logging statements should not use `error(..., exc_info=True)` (use `exception(...)` instead) - `G202` Logging statements should not use redundant `exc_info=True` in `exception` These violations are disabled by default. To enable them for your project, specify the code(s) in your `setup.cfg`: ```ini [flake8] enable-extensions=G ``` ## Motivation Our motivation has to do with balancing the needs of our team and those of our customers. On the one hand, developers and front-line support should be able to look at application logs. On the other hand, our customers don't want their data shared with anyone, including internal employees. The implementation approaches this in two ways: 1. By trying to prevent the use of string concatenation in logs (vs explicit variable passing in the standard logging `extra` dictionary) 2. By providing an (optional) mechanism for whitelisting which field names may appear in the `extra` dictionary Naturally, this _does not_ prevent developers from doing something like: ```python extra=dict( user_id=user.name, ) ``` but then avoiding a case like this falls back to other processes around pull-requests, code review and internal policy. %package -n python3-flake8-logging-format Summary: please add a summary manually as the author left a blank one Provides: python-flake8-logging-format BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-flake8-logging-format # flake8-logging-format Flake8 extension to validate (lack of) logging format strings ## What's This? Python [logging](https://docs.python.org/3/library/logging.html#logging.Logger.debug) supports a special `extra` keyword for passing a dictionary of user-defined attributes to include in a logging event. One way to ensure consistency and rigor in logging is to **always** use `extra` to pass non-constant data and, therefore, to **never** use format strings, concatenation, or other similar techniques to construct a log string. In other words, do this: ```python logger.info( "Hello {world}", extra=dict( world="Earth" ) ) ``` Instead of: ```python logger.info( "Hello {world}".format(world=Earth) ) ``` ## Extra Whitelist As a further level of rigor, we can enforce that `extra` dictionaries only use keys from a well-known whitelist. Usage: ```bash flake8 --enable-extra-whitelist ``` The built-in `Whitelist` supports plugins using `entry_points` with a key of `"logging.extra.whitelist"`. Each registered entry point must be a callable that returns an iterable of string. In some cases you may want to log sensitive data only in debugging scenarios. This is supported in 2 ways: 1. We do not check the logging.extra.whitelist for lines logged at the `debug` level 2. You may also prefix a keyword with 'debug\_' and log it at another level. You can safely assume these will be filtered out of shipped logs. ## Violations Detected - `G001` Logging statements should not use `string.format()` for their first argument - `G002` Logging statements should not use `%` formatting for their first argument - `G003` Logging statements should not use `+` concatenation for their first argument - `G004` Logging statements should not use `f"..."` for their first argument (only in Python 3.6+) - `G010` Logging statements should not use `warn` (use `warning` instead) - `G100` Logging statements should not use `extra` arguments unless whitelisted - `G101` Logging statement should not use `extra` arguments that clash with LogRecord fields - `G200` Logging statements should not include the exception in logged string (use `exception` or `exc_info=True`) - `G201` Logging statements should not use `error(..., exc_info=True)` (use `exception(...)` instead) - `G202` Logging statements should not use redundant `exc_info=True` in `exception` These violations are disabled by default. To enable them for your project, specify the code(s) in your `setup.cfg`: ```ini [flake8] enable-extensions=G ``` ## Motivation Our motivation has to do with balancing the needs of our team and those of our customers. On the one hand, developers and front-line support should be able to look at application logs. On the other hand, our customers don't want their data shared with anyone, including internal employees. The implementation approaches this in two ways: 1. By trying to prevent the use of string concatenation in logs (vs explicit variable passing in the standard logging `extra` dictionary) 2. By providing an (optional) mechanism for whitelisting which field names may appear in the `extra` dictionary Naturally, this _does not_ prevent developers from doing something like: ```python extra=dict( user_id=user.name, ) ``` but then avoiding a case like this falls back to other processes around pull-requests, code review and internal policy. %package help Summary: Development documents and examples for flake8-logging-format Provides: python3-flake8-logging-format-doc %description help # flake8-logging-format Flake8 extension to validate (lack of) logging format strings ## What's This? Python [logging](https://docs.python.org/3/library/logging.html#logging.Logger.debug) supports a special `extra` keyword for passing a dictionary of user-defined attributes to include in a logging event. One way to ensure consistency and rigor in logging is to **always** use `extra` to pass non-constant data and, therefore, to **never** use format strings, concatenation, or other similar techniques to construct a log string. In other words, do this: ```python logger.info( "Hello {world}", extra=dict( world="Earth" ) ) ``` Instead of: ```python logger.info( "Hello {world}".format(world=Earth) ) ``` ## Extra Whitelist As a further level of rigor, we can enforce that `extra` dictionaries only use keys from a well-known whitelist. Usage: ```bash flake8 --enable-extra-whitelist ``` The built-in `Whitelist` supports plugins using `entry_points` with a key of `"logging.extra.whitelist"`. Each registered entry point must be a callable that returns an iterable of string. In some cases you may want to log sensitive data only in debugging scenarios. This is supported in 2 ways: 1. We do not check the logging.extra.whitelist for lines logged at the `debug` level 2. You may also prefix a keyword with 'debug\_' and log it at another level. You can safely assume these will be filtered out of shipped logs. ## Violations Detected - `G001` Logging statements should not use `string.format()` for their first argument - `G002` Logging statements should not use `%` formatting for their first argument - `G003` Logging statements should not use `+` concatenation for their first argument - `G004` Logging statements should not use `f"..."` for their first argument (only in Python 3.6+) - `G010` Logging statements should not use `warn` (use `warning` instead) - `G100` Logging statements should not use `extra` arguments unless whitelisted - `G101` Logging statement should not use `extra` arguments that clash with LogRecord fields - `G200` Logging statements should not include the exception in logged string (use `exception` or `exc_info=True`) - `G201` Logging statements should not use `error(..., exc_info=True)` (use `exception(...)` instead) - `G202` Logging statements should not use redundant `exc_info=True` in `exception` These violations are disabled by default. To enable them for your project, specify the code(s) in your `setup.cfg`: ```ini [flake8] enable-extensions=G ``` ## Motivation Our motivation has to do with balancing the needs of our team and those of our customers. On the one hand, developers and front-line support should be able to look at application logs. On the other hand, our customers don't want their data shared with anyone, including internal employees. The implementation approaches this in two ways: 1. By trying to prevent the use of string concatenation in logs (vs explicit variable passing in the standard logging `extra` dictionary) 2. By providing an (optional) mechanism for whitelisting which field names may appear in the `extra` dictionary Naturally, this _does not_ prevent developers from doing something like: ```python extra=dict( user_id=user.name, ) ``` but then avoiding a case like this falls back to other processes around pull-requests, code review and internal policy. %prep %autosetup -n flake8-logging-format-0.9.0 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-flake8-logging-format -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Fri Apr 21 2023 Python_Bot - 0.9.0-1 - Package Spec generated