automatic import of python-flake8-logging-format

3 files changed, 347 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..6911ae9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/flake8-logging-format-0.9.0.tar.gz
diff --git a/python-flake8-logging-format.spec b/python-flake8-logging-format.spec
new file mode 100644
index 0000000..e730b70
--- /dev/null
+++ b/python-flake8-logging-format.spec
@@ -0,0 +1,345 @@
+%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
+* Mon Apr 10 2023 Python_Bot <Python_Bot@openeuler.org> - 0.9.0-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..fab6116
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+6368ee199e907145d5f864812ad23d01  flake8-logging-format-0.9.0.tar.gz