# packages

pkgId: 105c84a6a17a2711b7804c48a07a22e5985e5fe558a22eab226ebf79028be5df
name: python-debtcollector
arch: src
version: 2.5.0
epoch: 0
release: 1
url: https://docs.openstack.org/debtcollector/latest
rpm_license: Apache Software License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d10a184a-1975-47f9-abf6-36bb63a3eae2
location_href: 00003410-python-debtcollector/python-debtcollector-2.5.0-1.src.rpm
checksum_type: sha256
summary:
  A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non-destructive manner.


pkgId: bbdfddaf98a854ded604cfef8a4ce8f5f7586c3340d6e7d32e22e81ea55e0d27
name: python-debugpy
arch: src
version: 1.6.7
epoch: 0
release: 1
summary: An implementation of the Debug Adapter Protocol for Python
url: https://aka.ms/debugpy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-cbba11cb-2e35-4f62-ad13-760ed7d0117b
location_href: 00009037-python-debugpy/python-debugpy-1.6.7-1.src.rpm
checksum_type: sha256
description:
  debugpy is an implementation of the Debug Adapter Protocol for Python.

  The source code and the issue tracker is [hosted on GitHub](https://github.com/microsoft/debugpy/).


pkgId: a5b1b3774275386281ebd55787052088eb97c138c1b865ebbacf5cdda2b8626c
name: python-debugpy-debuginfo
arch: aarch64
version: 1.6.7
epoch: 0
release: 1
summary: Debug information for package python-debugpy
url: https://aka.ms/debugpy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-cbba11cb-2e35-4f62-ad13-760ed7d0117b
rpm_sourcerpm: python-debugpy-1.6.7-1.src.rpm
location_href: 00009037-python-debugpy/python-debugpy-debuginfo-1.6.7-1.aarch64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-debugpy.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: ffe9debb2a7337f300187d6125a475d1173be052e8f287f1db45e034455ce6fb
name: python-debugpy-debugsource
arch: aarch64
version: 1.6.7
epoch: 0
release: 1
summary: Debug sources for package python-debugpy
url: https://aka.ms/debugpy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-cbba11cb-2e35-4f62-ad13-760ed7d0117b
rpm_sourcerpm: python-debugpy-1.6.7-1.src.rpm
location_href: 00009037-python-debugpy/python-debugpy-debugsource-1.6.7-1.aarch64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-debugpy.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: f2cf9593d9ad6176467658eefef619067e3b591dd3427df0d588248183531e33
name: python-decopatch
arch: src
version: 1.4.10
epoch: 0
release: 1
summary: Create decorators easily in python.
url: https://github.com/smarie/python-decopatch
rpm_license: BSD 3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-eb3f5f23-6326-4c7d-aa50-d571e5783ce9
location_href: 00003413-python-decopatch/python-decopatch-1.4.10-1.src.rpm
checksum_type: sha256
description:
  [![Python versions](https://img.shields.io/pypi/pyversions/decopatch.svg)](https://pypi.python.org/pypi/decopatch/) [![Build Status](https://github.com/smarie/python-decopatch/actions/workflows/base.yml/badge.svg)](https://github.com/smarie/python-decopatch/actions/workflows/base.yml) [![Tests Status](https://smarie.github.io/python-decopatch/reports/junit/junit-badge.svg?dummy=8484744)](https://smarie.github.io/python-decopatch/reports/junit/report.html) [![Coverage Status](https://smarie.github.io/python-decopatch/reports/coverage/coverage-badge.svg?dummy=8484744)](https://smarie.github.io/python-decopatch/reports/coverage/index.html) [![codecov](https://codecov.io/gh/smarie/python-decopatch/branch/main/graph/badge.svg)](https://codecov.io/gh/smarie/python-decopatch) [![Flake8 Status](https://smarie.github.io/python-decopatch/reports/flake8/flake8-badge.svg?dummy=8484744)](https://smarie.github.io/python-decopatch/reports/flake8/index.html)

  [![Documentation](https://img.shields.io/badge/doc-latest-blue.svg)](https://smarie.github.io/python-decopatch/) [![PyPI](https://img.shields.io/pypi/v/decopatch.svg)](https://pypi.python.org/pypi/decopatch/) [![Downloads](https://pepy.tech/badge/decopatch)](https://pepy.tech/project/decopatch) [![Downloads per week](https://pepy.tech/badge/decopatch/week)](https://pepy.tech/project/decopatch) [![GitHub stars](https://img.shields.io/github/stars/smarie/python-decopatch.svg)](https://github.com/smarie/python-decopatch/stargazers)

  *python decorators made easy.*

  The documentation for users is available here: [https://smarie.github.io/python-decopatch/](https://smarie.github.io/python-decopatch/)

  A readme for developers is available here: [https://github.com/smarie/python-decopatch](https://github.com/smarie/python-decopatch)


pkgId: 426476089045c928bc650aa61ea3dcbd287dc7af7d1962a0ae27bc1c24b7ff5d
name: python-decorator
arch: src
version: 5.1.1
epoch: 0
release: 1
summary: Decorators for Humans
url: https://github.com/micheles/decorator
rpm_license: new BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ba3e46ab-67e5-455e-8ce7-8f1d7082fbdd
location_href: 00008928-python-decorator/python-decorator-5.1.1-1.src.rpm
checksum_type: sha256
description:
  The goal of the decorator module is to make it easy to define
  signature-preserving function decorators and decorator factories.
  It also includes an implementation of multiple dispatch and other niceties
  (please check the docs). It is released under a two-clauses
  BSD license, i.e. basically you can do whatever you want with it but I am not
  responsible.


pkgId: 11833f52a2cdc6236ed65f29f417b76128f2473b54a48e93eec94d8df471dd69
name: python-deep_merge
arch: src
version: 0.0.4
epoch: 0
release: 1
summary: A simple utility for merging python dictionaries.
url: https://github.com/halfak/deep_merge
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f1c7b567-4d14-4187-ba58-56e068131c57
location_href: 00011197-python-deep-merge/python-deep_merge-0.0.4-1.src.rpm
checksum_type: sha256
description:
  This library contains a simple utility for deep-merging dictionaries and the
  data structures they contain.

  * **Installation:** ``pip install deep_merge``
  * **Documentation:** https://pythonhosted.org/deep_merge
  * **Repositiory:** https://github.com/halfak/deep_merge
  * **License:** MIT



      >>> import deep_merge
      >>>
      >>> print(deep_merge.merge({'a': {'b': 10}}, {'a': {'c': 5}}))
      {'a': {'b': 10, 'c': 5}}

  Note that the first parameter is modified and will be assigned the return value.

      >>> d1 = {}
      >>> d2 = {'a': 1}
      >>> deep_merge.merge(d1, d2)
      >>> print(d1)
      {'a': 1}


  * Aaron Halfaker -- https://github.com/halfak


pkgId: bf7c381728984fa6b0c7a1c567444807ae099728275662866bbdb579a2b9a6eb
name: python-deepdiff
arch: src
version: 6.2.3
epoch: 0
release: 1
url: https://github.com/seperman/deepdiff
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-3ec35eee-8b36-41ed-bf35-ca5a574acfb3
location_href: 00003414-python-deepdiff/python-deepdiff-6.2.3-1.src.rpm
checksum_type: sha256
summary:
  Deep Difference and Search of any Python object/data. Recreate objects by adding adding deltas to each other.

description:
  ![Downloads](https://img.shields.io/pypi/dm/deepdiff.svg?style=flat)
  ![Python Versions](https://img.shields.io/pypi/pyversions/deepdiff.svg?style=flat)
  ![License](https://img.shields.io/pypi/l/deepdiff.svg?version=latest)
  [![Build Status](https://github.com/seperman/deepdiff/workflows/Unit%20Tests/badge.svg)](https://github.com/seperman/deepdiff/actions)
  [![codecov](https://codecov.io/gh/seperman/deepdiff/branch/master/graph/badge.svg?token=KkHZ3siA3m)](https://codecov.io/gh/seperman/deepdiff)



  - DeepDiff: Deep Difference of dictionaries, iterables, strings and other objects. It will recursively look for all the changes.
  - DeepSearch: Search for objects within other objects.
  - DeepHash: Hash any object based on their content.

  Tested on Python 3.7+ and PyPy3.

  - **[Documentation](https://zepworks.com/deepdiff/6.2.3/)**



  Please check the [ChangeLog](CHANGELOG.md) file for the detailed information.

  DeepDiff 6-2-0

  - Major improvement in the diff report for lists when items are all hashable and the order of items is important.

  DeepDiff 6-1-0

  - DeepDiff.affected_paths can be used to get the list of all paths where a change, addition, or deletion was reported for.
  - DeepDiff.affected_root_keys can be used to get the list of all paths where a change, addition, or deletion was reported for.
  - Bugfix: ValueError when using Decimal 0.x #339  by [Enric Pou](https://github.com/epou)
  - Serialization of UUID

  DeepDiff 6-0-0

  - [Exclude obj callback strict](https://github.com/seperman/deepdiff/pull/320/files) parameter is added to DeepDiff by Mikhail Khviyuzov [mskhviyu](https://github.com/mskhviyu).
  - A fix for diffing using `iterable_compare_func` with nested objects by [dtorres-sf](https://github.com/dtorres-sf) who originally contributed this feature.

  Note: There are no breaking changes in DeepDiff 6 compared to the latest DeepDiff 5 releases.





  `pip install deepdiff`

  If you want to use DeepDiff from commandline:

  `pip install "deepdiff[cli]"`



  ```python
  >>> from deepdiff import DeepDiff  # For Deep Difference of 2 objects
  >>> from deepdiff import grep, DeepSearch  # For finding if item exists in an object
  >>> from deepdiff import DeepHash  # For hashing objects based on their contents
  ```

  Note: if you want to use DeepDiff via commandline, make sure to run `pip install "deepdiff[cli]"`. Then you can access the commands via:

  - DeepDiff
      - `$ deep diff --help`
  - Delta
      - `$ deep patch --help`
  - grep
      - `$ deep grep --help`
  - extract
      - `$ deep extract --help`



  DeepDiff gets the difference of 2 objects.

  > - Please take a look at the [DeepDiff docs](https://zepworks.com/deepdiff/6.2.3/diff.html)
  > - The full documentation of all modules can be found on <https://zepworks.com/deepdiff/6.2.3/>
  > - Tutorials and posts about DeepDiff can be found on <https://zepworks.com/tags/deepdiff/>



  > Note: This is just a brief overview of what DeepDiff can do. Please visit <https://zepworks.com/deepdiff/6.2.3/> for full documentation.



  ```python
  >>> t1 = {1:1, 2:2, 3:3, 4:{"a":"hello", "b":[1, 2, 3]}}
  >>> t2 = {1:1, 2:2, 3:3, 4:{"a":"hello", "b":[1, 3, 2, 3]}}
  >>> ddiff = DeepDiff(t1, t2, ignore_order=True)
  >>> print (ddiff)
  {}
  ```



  This flag ONLY works when ignoring order is enabled.

  ```python
  t1 = [1, 3, 1, 4]
  t2 = [4, 4, 1]
  ddiff = DeepDiff(t1, t2, ignore_order=True, report_repetition=True)
  print(ddiff)
  ```

  which will print you:

  ```python
  {'iterable_item_removed': {'root[1]': 3},
    'repetition_change': {'root[0]': {'old_repeat': 2,
                                      'old_indexes': [0, 2],
                                      'new_indexes': [2],
                                      'value': 1,
                                      'new_repeat': 1},
                          'root[3]': {'old_repeat': 1,
                                      'old_indexes': [3],
                                      'new_indexes': [0, 1],
                                      'value': 4,
                                      'new_repeat': 2}}}
  ```



  ```python
  >>> l1 = logging.getLogger("test")
  >>> l2 = logging.getLogger("test2")
  >>> t1 = {"log": l1, 2: 1337}
  >>> t2 = {"log": l2, 2: 1337}
  >>> print(DeepDiff(t1, t2, exclude_types={logging.Logger}))
  {}
  ```



  ```python
  >>> t1 = {"for life": "vegan", "ingredients": ["no meat", "no eggs", "no dairy"]}
  >>> t2 = {"for life": "vegan", "ingredients": ["veggies", "tofu", "soy sauce"]}
  >>> print (DeepDiff(t1, t2, exclude_paths={"root['ingredients']"}))
  {}
  ```




  You can also exclude using regular expressions by using `exclude_regex_paths` and pass a set or list of path regexes to exclude. The items in the list could be raw regex strings or compiled regex objects.

  ```python
  >>> t1 = [{'a': 1, 'b': 2}, {'c': 4, 'b': 5}]
  >>> t2 = [{'a': 1, 'b': 3}, {'c': 4, 'b': 5}]
  >>> print(DeepDiff(t1, t2, exclude_regex_paths={r"root\[\d+\]\['b'\]"}))
  {}
  >>> exclude_path = re.compile(r"root\[\d+\]\['b'\]")
  >>> print(DeepDiff(t1, t2, exclude_regex_paths=[exclude_path]))
  {}
  ```



  Digits **after** the decimal point. Internally it uses "{:.Xf}".format(Your Number) to compare numbers where X=significant_digits

  ```python
  >>> t1 = Decimal('1.52')
  >>> t2 = Decimal('1.57')
  >>> DeepDiff(t1, t2, significant_digits=0)
  {}
  >>> DeepDiff(t1, t2, significant_digits=1)
  {'values_changed': {'root': {'old_value': Decimal('1.52'), 'new_value': Decimal('1.57')}}}
  ```



  ```py
  >>> from deepdiff import DeepDiff
  >>> from pprint import pprint
  >>> t1 = [1, 2, 3]
  >>> t2 = [1.0, 2.0, 3.0]
  >>> ddiff = DeepDiff(t1, t2)
  >>> pprint(ddiff, indent=2)
  { 'type_changes': { 'root[0]': { 'new_type': <class 'float'>,
                           'new_value': 1.0,
                           'old_type': <class 'int'>,
                           'old_value': 1},
              'root[1]': { 'new_type': <class 'float'>,
                           'new_value': 2.0,
                           'old_type': <class 'int'>,
                           'old_value': 2},
              'root[2]': { 'new_type': <class 'float'>,
                           'new_value': 3.0,
                           'old_type': <class 'int'>,
                           'old_value': 3}}}
  >>> ddiff = DeepDiff(t1, t2, ignore_type_in_groups=[(int, float)])
  {}
  ```



  Starting with DeepDiff v 3, there are two different views into your diffed data: text view (original) and tree view (new).



  Text view is the original and currently the default view of DeepDiff.

  It is called text view because the results contain texts that represent the path to the data:

  Example of using the text view.

  ```python
  >>> from deepdiff import DeepDiff
  >>> t1 = {1:1, 3:3, 4:4}
  >>> t2 = {1:1, 3:3, 5:5, 6:6}
  >>> ddiff = DeepDiff(t1, t2)
  >>> print(ddiff)
  {'dictionary_item_added': {'root[5]', 'root[6]'}, 'dictionary_item_removed': {'root[4]'}}
  ```

  So for example `ddiff['dictionary_item_removed']` is a set if strings thus this is called the text view.

      The following examples are using the *default text view.*
      The Tree View is introduced in DeepDiff v3
      and provides traversing capabilities through your diffed data and more!
      Read more about the Tree View at the [tree view section](#tree-view) of this page.




  Starting the version v3 You can choose the view into the deepdiff results.
  The tree view provides you with tree objects that you can traverse through to find the parents of the objects that are diffed and the actual objects that are being diffed.




  ```python
  >>> from deepdiff import DeepDiff
  >>> from pprint import pprint
  >>> t1 = {1:1, 2:2, 3:3}
  >>> t2 = {1:1, 2:4, 3:3}
  >>> ddiff_verbose0 = DeepDiff(t1, t2, verbose_level=0, view='tree')
  >>> ddiff_verbose0
  {'values_changed': {<root[2]>}}
  >>>
  >>> ddiff_verbose1 = DeepDiff(t1, t2, verbose_level=1, view='tree')
  >>> ddiff_verbose1
  {'values_changed': {<root[2] t1:2, t2:4>}}
  >>> set_of_values_changed = ddiff_verbose1['values_changed']
  >>> # since set_of_values_changed includes only one item in a set
  >>> # in order to get that one item we can:
  >>> (changed,) = set_of_values_changed
  >>> changed  # Another way to get this is to do: changed=list(set_of_values_changed)[0]
  <root[2] t1:2, t2:4>
  >>> changed.t1
  2
  >>> changed.t2
  4
  >>> # You can traverse through the tree, get to the parents!
  >>> changed.up
  <root t1:{1: 1, 2: 2,...}, t2:{1: 1, 2: 4,...}>
  ```



  In order to convert the DeepDiff object into a normal Python dictionary, use the to_dict() method.
  Note that to_dict will use the text view even if you did the diff in tree view.

  Example:

  ```python
  >>> t1 = {1: 1, 2: 2, 3: 3, 4: {"a": "hello", "b": [1, 2, 3]}}
  >>> t2 = {1: 1, 2: 2, 3: 3, 4: {"a": "hello", "b": "world\n\n\nEnd"}}
  >>> ddiff = DeepDiff(t1, t2, view='tree')
  >>> ddiff.to_dict()
  {'type_changes': {"root[4]['b']": {'old_type': <class 'list'>, 'new_type': <class 'str'>, 'old_value': [1, 2, 3], 'new_value': 'world\n\n\nEnd'}}}
  ```

  In order to do safe json serialization, use the to_json() method.

  Example:

  ```python
  >>> t1 = {1: 1, 2: 2, 3: 3, 4: {"a": "hello", "b": [1, 2, 3]}}
  >>> t2 = {1: 1, 2: 2, 3: 3, 4: {"a": "hello", "b": "world\n\n\nEnd"}}
  >>> ddiff = DeepDiff(t1, t2, view='tree')
  >>> ddiff.to_json()
  '{"type_changes": {"root[4][\'b\']": {"old_type": "list", "new_type": "str", "old_value": [1, 2, 3], "new_value": "world\\n\\n\\nEnd"}}}'
  ```


  > - Please take a look at the [DeepDiff docs](https://zepworks.com/deepdiff/6.2.3/diff.html)
  > - The full documentation can be found on <https://zepworks.com/deepdiff/6.2.3/>




  DeepDiff comes with a utility to find the path to the item you are looking for.
  It is called DeepSearch and it has a similar interface to DeepDiff.

  Let's say you have a huge nested object and want to see if any item with the word `somewhere` exists in it.
  Just grep through your objects as you would in shell!

  ```py
  from deepdiff import grep
  obj = {"long": "somewhere", "string": 2, 0: 0, "somewhere": "around"}
  ds = obj | grep("somewhere")
  print(ds)
  ```

  Which will print:

  ```py
  {'matched_paths': {"root['somewhere']"},
   'matched_values': {"root['long']"}}
  ```

  And you can pass all the same kwargs as DeepSearch to grep too:

  ```py
  >>> obj | grep(item, verbose_level=2)
  {'matched_paths': {"root['somewhere']": 'around'}, 'matched_values': {"root['long']": 'somewhere'}}
  ```

  > - Please take a look at the [DeepSearch docs](https://zepworks.com/deepdiff/6.2.3/dsearch.html)
  > - The full documentation can be found on <https://zepworks.com/deepdiff/6.2.3/>


  (New in v4-0-0)

  DeepHash is designed to give you hash of ANY python object based on its contents even if the object is not considered hashable!
  DeepHash is supposed to be deterministic in order to make sure 2 objects that contain the same data, produce the same hash.

  > - Please take a look at the [DeepHash docs](https://zepworks.com/deepdiff/6.2.3/deephash.html)
  > - The full documentation can be found on <https://zepworks.com/deepdiff/6.2.3/>

  Let's say you have a dictionary object.

  ```py
  >>> from deepdiff import DeepHash
  >>>
  >>> obj = {1: 2, 'a': 'b'}
  ```

  If you try to hash it:

  ```py
  >>> hash(obj)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unhashable type: 'dict'
  ```

  But with DeepHash:

  ```py
  >>> from deepdiff import DeepHash
  >>> obj = {1: 2, 'a': 'b'}
  >>> DeepHash(obj)
  {4355639248: 2468916477072481777512283587789292749, 4355639280: -35787773492556653776377555218122431491, 4358636128: -88390647972316138151822486391929534118, 4358009664: 8833996863197925870419376694314494743, 4357467952: 34150898645750099477987229399128149852}
  ```

  So what is exactly the hash of obj in this case?
  DeepHash is calculating the hash of the obj and any other object that obj contains.
  The output of DeepHash is a dictionary of object IDs to their hashes.
  In order to get the hash of obj itself, you need to use the object (or the id of object) to get its hash:

  ```py
  >>> hashes = DeepHash(obj)
  >>> hashes[obj]
  34150898645750099477987229399128149852
  ```

  Which you can write as:

  ```py
  >>> hashes = DeepHash(obj)[obj]
  ```

  At first it might seem weird why DeepHash(obj)[obj] but remember that DeepHash(obj) is a dictionary of hashes of all other objects that obj contains too.


  > - Please take a look at the [DeepHash docs](https://zepworks.com/deepdiff/6.2.3/deephash.html)
  > - The full documentation can be found on <https://zepworks.com/deepdiff/6.2.3/>




  `result` is the output of the function that is being tests.
  `expected` is the expected output of the function.

  ```python
  self.assertEqual(DeepDiff(expected, result), {})
  ```

  or if you are using Pytest:


  ```python
  assert not DeepDiff(expected, result)
  ```

  In other words, assert that there is no diff between the expected and the result.



  Unlike [Json Patch](https://tools.ietf.org/html/rfc6902) which is designed only for Json objects, DeepDiff is designed specifically for almost all Python types. In addition to that, DeepDiff checks for type changes and attribute value changes that Json Patch does not cover since there are no such things in Json. Last but not least, DeepDiff gives you the exact path of the item(s) that were changed in Python syntax.

  Example in Json Patch for replacing:

  `{ "op": "replace", "path": "/a/b/c", "value": 42 }`

  Example in DeepDiff for the same operation:

  ```python
  >>> item1 = {'a':{'b':{'c':'foo'}}}
  >>> item2 = {'a':{'b':{'c':42}}}
  >>> DeepDiff(item1, item2)
  {'type_changes': {"root['a']['b']['c']": {'old_type': <type 'str'>, 'new_value': 42, 'old_value': 'foo', 'new_type': <type 'int'>}}}
  ```




  <https://zepworks.com/deepdiff/current/>




  I was honored to give a talk about the basics of how DeepDiff does what it does at Pycon 2016. Please check out the video and let me know what you think:

  [Diff It To Dig It Video](https://www.youtube.com/watch?v=J5r99eJIxF4)
  And here is more info: <http://zepworks.com/blog/diff-it-to-digg-it/>



  Please take a look at the [CHANGELOG](CHANGELOG.md) file.



  We use bump2version to bump and tag releases.

  ```bash
  git checkout master && git pull
  bumpversion {patch|minor|major}
  git push && git push --tags
  ```



  1. Please make your PR against the dev branch
  2. Please make sure that your PR has tests. Since DeepDiff is used in many sensitive data driven projects, we strive to maintain around 100% test coverage on the code.

  Please run `pytest --cov=deepdiff --runslow` to see the coverage report. Note that the `--runslow` flag will run some slow tests too. In most cases you only want to run the fast tests which so you wont add the `--runslow` flag.

  Or to see a more user friendly version, please run: `pytest --cov=deepdiff --cov-report term-missing --runslow`.

  Thank you!



  How to cite this library (APA style):

      Dehpour, S. (2022). DeepDiff (Version 6.2.3) [Software]. Available from https://github.com/seperman/deepdiff.

  How to cite this library (Chicago style):

      Dehpour, Sep. 2022. DeepDiff (version 6.2.3).



  Please take a look at the [AUTHORS](AUTHORS.md) file.


pkgId: d9f98c707a3de7f62895075a2ce3a9fce5844e854101b98ed1f747619974ab43
name: python-deepdiff
arch: src
version: 6.3.0
epoch: 0
release: 1
url: https://github.com/seperman/deepdiff
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-45b6ec69-48c1-46aa-8fd2-427f3fd68fa2
location_href: 00006774-python-deepdiff/python-deepdiff-6.3.0-1.src.rpm
checksum_type: sha256
summary:
  Deep Difference and Search of any Python object/data. Recreate objects by adding adding deltas to each other.

description:
  ![Downloads](https://img.shields.io/pypi/dm/deepdiff.svg?style=flat)
  ![Python Versions](https://img.shields.io/pypi/pyversions/deepdiff.svg?style=flat)
  ![License](https://img.shields.io/pypi/l/deepdiff.svg?version=latest)
  [![Build Status](https://github.com/seperman/deepdiff/workflows/Unit%20Tests/badge.svg)](https://github.com/seperman/deepdiff/actions)
  [![codecov](https://codecov.io/gh/seperman/deepdiff/branch/master/graph/badge.svg?token=KkHZ3siA3m)](https://codecov.io/gh/seperman/deepdiff)



  - [DeepDiff](https://zepworks.com/deepdiff/current/diff.html): Deep Difference of dictionaries, iterables, strings, and ANY other object.
  - [DeepSearch](https://zepworks.com/deepdiff/current/dsearch.html): Search for objects within other objects.
  - [DeepHash](https://zepworks.com/deepdiff/current/deephash.html): Hash any object based on their content.
  - [Delta](https://zepworks.com/deepdiff/current/delta.html): Store the difference of objects and apply them to other objects.
  - [Extract](https://zepworks.com/deepdiff/current/extract.html): Extract an item from a nested Python object using its path.
  - [commandline](https://zepworks.com/deepdiff/current/commandline.html): Use DeepDiff from commandline.

  Tested on Python 3.7+ and PyPy3.

  - **[Documentation](https://zepworks.com/deepdiff/6.3.0/)**



  Please check the [ChangeLog](CHANGELOG.md) file for the detailed information.

  DeepDiff 6-3-0

  - `PrefixOrSuffixOperator`: This operator will skip strings that are suffix or prefix of each other.
  - `include_obj_callback` and `include_obj_callback_strict` are added by [Håvard Thom](https://github.com/havardthom).
  - Fixed a corner case where numpy's `np.float32` nans are not ignored when using `ignore_nan_equality` by [Noam Gottlieb](https://github.com/noamgot)
  - `orjson` becomes optional again.
  - Fix for `ignore_type_in_groups` with numeric values so it does not report number changes when the number types are different.

  DeepDiff 6-2-0

  - Major improvement in the diff report for lists when items are all hashable and the order of items is important.






  `pip install deepdiff`

  If you want to use DeepDiff from commandline:

  `pip install "deepdiff[cli]"`

  If you want to improve the performance of DeepDiff with certain functionalities such as improved json serialization:

  `pip install "deepdiff[optimize]"`



  <https://zepworks.com/deepdiff/current/>



  Please take a look at the [CHANGELOG](CHANGELOG.md) file.



  1. Please make your PR against the dev branch
  2. Please make sure that your PR has tests. Since DeepDiff is used in many sensitive data driven projects, we strive to maintain around 100% test coverage on the code.

  Please run `pytest --cov=deepdiff --runslow` to see the coverage report. Note that the `--runslow` flag will run some slow tests too. In most cases you only want to run the fast tests which so you wont add the `--runslow` flag.

  Or to see a more user friendly version, please run: `pytest --cov=deepdiff --cov-report term-missing --runslow`.

  Thank you!



  How to cite this library (APA style):

      Dehpour, S. (2022). DeepDiff (Version 6.3.0) [Software]. Available from https://github.com/seperman/deepdiff.

  How to cite this library (Chicago style):

      Dehpour, Sep. 2022. DeepDiff (version 6.3.0).



  Please take a look at the [AUTHORS](AUTHORS.md) file.


pkgId: b1a73990945bc19244fda47a5cde8592917f80dc2eab46141a01f36ed992f359
name: python-deepspeed
arch: src
version: 0.8.3
epoch: 0
release: 1
summary: DeepSpeed library
url: http://deepspeed.ai
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c6e4271b-e857-4b98-b631-8c55498e64f1
location_href: 00013230-python-deepspeed/python-deepspeed-0.8.3-1.src.rpm
checksum_type: sha256
description:
  [DeepSpeed](https://www.deepspeed.ai/) is an easy-to-use deep learning optimization software suite that enables unprecedented scale and speed for Deep Learning Training and Inference. With DeepSpeed you can:
  * Train/Inference dense or sparse models with billions or trillions of parameters
  * Achieve excellent system throughput and efficiently scale to thousands of GPUs
  * Train/Inference on resource constrained GPU systems
  * Achieve unprecedented low latency and high throughput for inference


pkgId: b995f6d6f483eeb6e47fbc83940585c9b5c9ff25691c664746a779b13acde7c8
name: python-defcon
arch: src
version: 0.10.2
epoch: 0
release: 1
summary: A set of flexible objects for representing UFO data.
url: https://github.com/robotools/defcon
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4e7527d9-96a0-4d2c-8b3b-8f9821202103
location_href: 00003415-python-defcon/python-defcon-0.10.2-1.src.rpm
checksum_type: sha256
description:
  Defcon is a set of UFO based objects optimized for use in font editing
  applications. The objects are built to be lightweight, fast and
  flexible. The objects are very bare-bones and they are not meant to be
  end-all, be-all objects. Rather, they are meant to provide base
  functionality so that you can focus on your application’s behavior, not
  object observing or maintaining cached data. Defcon implements UFO3 as
  described by the `UFO font format <http://unifiedfontobject.org>`_. If
  needed, the
  `ufo2-deprecated <https://github.com/typesupply/defcon/tree/ufo2-deprecated>`_
  branch has the older, UFO2, version of Defcon.
  Install
  ~~~~~~~
  To download and install the latest stable release of defcon from the
  `Python Package Index <https://pypi.python.org/pypi/defcon>`_, use the
  `pip <https://pip.pypa.io/en/stable/installing/>`_ command line tool:
    pip install --upgrade defcon
  To install with the `fontPens <https://github.com/robofab-developers/fontPens>`_ package —used for ``Glyph.correctDirection()`` and ``Contour.contourInside()``— do:
    pip install --upgrade defcon[pens]
  To optionally install defcon with support for `lxml <https://github.com/lxml/lxml>`_,
  a faster XML reader and writer library, you can do:
    pip install --upgrade defcon[lxml]
  You can separate multiple extras using a comma: ``defcon[pens,lxml]``.
  Documentation
  ~~~~~~~~~~~~~
  Documentation for Defcon lives at
  `defcon.robotools.dev <http://defcon.robotools.dev/en/latest/>`_.
  Copyrights
  ~~~~~~~~~~
  This package is distributed under the MIT license. See the
  `license <License.txt>`_. Defcon is built in
  `Python <http://www.python.org>`_. Parts of RoboFab use
  `fontTools <https://github.com/behdad/fonttools>`_, an OpenSource font
  toolkit started by Just van Rossum. Parts of Defcon implement the
  Property List file format in XML, copyright
  `Apple Computer <http://www.apple.com>`_. Parts of Defcon implement tables and
  names from PostScript and the OpenType FDK, copyright
  `Adobe <http://www.adobe.com>`_.


pkgId: 687f642c5da4c123a020e804a6420c6cbca84bd6efcf414133faf9bb93097c14
name: python-delighted
arch: src
version: 4.1.0
epoch: 0
release: 1
summary: Delighted API Python Client.
url: https://delighted.com/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fde18bbf-067e-4adf-bb4e-bd1c9e95ea92
location_href: 00011025-python-delighted/python-delighted-4.1.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/delighted/delighted-python.svg?branch=master)](https://travis-ci.org/delighted/delighted-python)



  Official Python client for the [Delighted API](https://delighted.com/docs/api).



  ```
  pip install --upgrade delighted
  ```

  or

  ```
  easy_install --upgrade delighted
  ```



  If you previously used the python package named `delighted-python`, please note that the package name is now just `delighted`.



  To get started, you need to configure the client with your secret API key.

  ```python
  import delighted
  delighted.api_key = 'YOUR_API_KEY'
  ```

  For further options, read the [advanced configuration section](#advanced-configuration).

  **Note:** Your API key is secret, and you should treat it like a password. You can find your API key in your Delighted account, under *Settings* > *API*.



  Adding/updating people and scheduling surveys:

  ```python

  person1 = delighted.Person.create(email='foo+test1@delighted.com')


  person2 = delighted.Person.create(email='foo+test2@delighted.com', delay=60)


  person3 = delighted.Person.create(email='foo+test3@delighted.com', send=False)



  person4 = delighted.Person.create(
          email='foo+test4@delighted.com',
          name='Joe Bloggs',
          properties={'customer_id': 123, 'country': 'USA',
                      'question_product_name': 'The London Trench'},
          delay=30)



  updated_person1 = delighted.Person.create(email='foo+test1@delighted.com',
                                            name='James Scott', send=False)
  ```

  Unsubscribing people:

  ```python

  delighted.Unsubscribe.create(person_email='foo+test1@delighted.com')
  ```

  Listing people:

  ```python


  people = delighted.Person.list()
  while True:
      try:
          for person in people.auto_paging_iter():
              
      except TooManyRequestsError as e:
          
          e.retry_after
          continue


  people = delighted.Person.list(auto_handle_rate_limits=True)
  for person in people.auto_paging_iter():
      
  ```

  Listing people who have unsubscribed:

  ```python

  delighted.Unsubscribe.all()
  delighted.Unsubscribe.all(page=2)
  ```

  Listing people whose emails have bounced:

  ```python

  delighted.Bounce.all()
  delighted.Bounce.all(page=2)
  ```

  Deleting a person and all of the data associated with them:

  ```python

  delighted.Person.delete(id=42)

  delighted.Person.delete(email='test@example.com')

  delighted.Person.delete(phone_number='+14155551212')
  ```

  Deleting pending survey requests

  ```python

  delighted.SurveyRequest.delete_pending(person_email='foo+test1@delighted.com')
  ```

  Adding survey responses:

  ```python

  survey_response1 = delighted.SurveyResponse.create(person=person1.id,
                                                     score=10)


  survey_response2 = delighted.SurveyResponse.create(person=person1.id,
                                                     score=5,
                                                     comment='Really nice.')
  ```

  Retrieving a survey response:

  ```python

  survey_response3 = delighted.SurveyResponse.retrieve('123')
  ```

  Updating survey responses:

  ```python

  survey_response4 = delighted.SurveyResponse.retrieve('234')
  survey_response4.score = 10
  survey_response4.save()



  survey_response4.person_properties = {'segment': 'Online'}
  survey_response4.save()



  survey_response4.person = '321'
  survey_response4.save()

  ```

  Listing survey responses:

  ```python

  survey_responses_page1 = delighted.SurveyResponse.all()
  survey_responses_page2 = delighted.SurveyResponse.all(page=2)


  survey_responses_page1_expanded = delighted.SurveyResponse.all(expand=['person'])
  survey_responses_page1_expanded[0].person



  survey_responses_page1_trend = delighted.SurveyResponse.all(trend='123')


  survey_responses_page1_desc = delighted.SurveyResponse.all(order='desc')


  import pytz
  timezone = pytz.timezone('America/Chicago')
  filtered_survey_responses = delighted.SurveyResponse.all(
      page=5,
      per_page=100,
      since=timezone.localize(datetime.datetime(2014, 3, 1)),
      until=timezone.localize(datetime.datetime(2014, 4, 30))
  )
  ```

  Retrieving metrics:

  ```python

  metrics = delighted.Metrics.retrieve()



  metrics = delighted.Metrics.retrieve(trend='123')


  import pytz
  timezone = pytz.timezone('America/Chicago')
  metrics = delighted.Metrics.retrieve(
      since=timezone.localize(datetime.datetime(2013, 10, 1)),
      until=timezone.localize(datetime.datetime(2013, 11, 1))
  )
  ```

  Managing Autopilot:

  ```python

  autopilot = delighted.AutopilotConfiguration.retrieve('email')


  people_autopilot = delighted.AutopilotMembership.forEmail().list(auto_handle_rate_limits=True)
  for person in people_autopilot.auto_paging_iter():
    


  autopilot = delighted.AutopilotMembership.forEmail().create(person_email='test@example.com')


  properties = {'customer_id': 123, 'country': 'USA', 'question_product_name': 'The London Trench'}
  autopilot = delighted.AutopilotMembership.forSms().create(person_phone_number='+14155551212', properties=properties)


  delighted.AutopilotMembership.forSms().delete(person_id=42)


  delighted.AutopilotMembership.forEmail().delete(person_email='test@example.com')


  delighted.AutopilotMembership.forSms().delete(person_phone_number='+14155551212')
  ```



  If a request is rate limited, a `TooManyRequestsError` exception is raised. You can rescue that exception to implement exponential backoff or retry strategies. The exception provides a `retry_after` attribute to tell you how many seconds you should wait before retrying. For example:

  ```python
  try:
      metrics = delighted.Metrics.retrieve()
  except delighted.errors.TooManyRequestsError as err:
      retry_after_seconds = err.retry_after
      
      
  ```



  The following options are configurable for the client:

  ```python
  delighted.api_key
  delighted.api_base_url # default: 'https://api.delighted.com/v1/'
  delighted.http_adapter # default: delighted.HTTPAdapter
  ```

  By default, a shared instance of `delighted.Client` is created lazily in `delighted.get_shared_client()`. If you want to create your own client, perhaps for test or if you have multiple API keys, you can:

  ```python

  import delighted
  from delighted import Client
  client = Client(api_key='API_KEY',
                  api_base_url='https://api.delighted.com/v1/',
                  http_adapter=HTTPAdapter())
  metrics_from_custom_client = delighted.Metrics.retrieve(client=client)


  delighted.shared_client = delighted.Client(
      api_key='API_KEY',
      api_base_url='https://api.delighted.com/v1/',
      http_adapter=delighted.HTTPAdapter()
  )
  metrics_from_custom_shared_client = delighted.Metrics.retrieve()
  ```



  - 2.6+, 3.3+ (PyPy supported)



  1. Fork it
  2. Create your feature branch (`git checkout -b my-new-feature`)
  3. Run the tests (`tox`)
  4. Commit your changes (`git commit -am 'Add some feature'`)
  5. Push to the branch (`git push origin my-new-feature`)
  6. Create new Pull Request



  1. Bump the version in `delighted/__init__.py`.
  2. Update the README and CHANGELOG as needed.
  3. Tag the commit for release.
  4. Create the distribution `python setup.py sdist`
  5. Update the package against PyPI's test server with [twine](https://pypi.org/project/twine/)
  `twine upload --repository-url https://test.pypi.org/legacy/ dist/TEST_PACKAGE_NAME`.
  6. If (4 and 5) work, repeat all steps, then push to PyPI's live servers with `twine upload dist/PACKAGE_NAME`.



  Originally by [Jason Pearson](https://github.com/kaeawc). Graciously transfered and now officially maintained by Delighted.


pkgId: 023a40a58c59fe71166d5112bf81df3da8b732288430b89028f3e813ca3b067c
name: python-delta-sharing
arch: src
version: 0.6.3
epoch: 0
release: 1
summary: Python Connector for Delta Sharing
url: https://github.com/delta-io/delta-sharing/
rpm_license: Apache-2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-df31b305-652f-4c1d-8c49-08097c682649
location_href: 00012443-python-delta-sharing/python-delta-sharing-0.6.3-1.src.rpm
checksum_type: sha256
description:
  [Delta Sharing](https://delta.io/sharing) is an open protocol for secure real-time exchange of large datasets, which enables secure data sharing across different computing platforms. It lets organizations share access to existing [Delta Lake](https://delta.io) and [Apache Parquet](https://parquet.apache.org) tables with other organizations, who can then directly read the table in Pandas, Apache Spark, or any other software that implements the open protocol.

  This is the Python client library for Delta Sharing, which lets you load shared tables as [pandas](https://pandas.pydata.org/) DataFrames or as [Apache Spark](http://spark.apache.org/) DataFrames if running in PySpark with the [Apache Spark Connector library](https://github.com/delta-io/delta-sharing#set-up-apache-spark).



  1. Install using `pip install delta-sharing`.
  2. To use the Python Connector, see [the project docs](https://github.com/delta-io/delta-sharing) for details.



  This README only contains basic information about the Delta Sharing Python Connector. Please read [the project documentation](https://github.com/delta-io/delta-sharing) for full usage details.


pkgId: 3af7448dd20048859f19e4b8f919ce8a0f309f9b306ffa55a83fccbf09ec2696
name: python-demjson
arch: src
version: 2.2.4
epoch: 0
release: 1
summary: encoder, decoder, and lint/validator for JSON (JavaScript Object Notation) compliant with RFC 7159
url: http://deron.meranda.us/python/demjson/
rpm_license: GNU LGPL 3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-22966c68-eac0-4720-9839-6b0b8df6114a
location_href: 00003416-python-demjson/python-demjson-2.2.4-1.src.rpm
checksum_type: sha256
description:
  The "demjson" module, and the included "jsonlint" script, provide methods
  for encoding and decoding JSON formatted data, as well as checking JSON
  data for errors and/or portability issues.  The jsonlint command/script
  can be used from the command line without needing any programming.

  Although the standard Python library now includes basic JSON support
  (which it did not when demjson was first written), this module
  provides a much more comprehensive implementation with many features
  not found elsewhere.  It is especially useful for error checking or
  for parsing JavaScript data which may not strictly be valid JSON data.


pkgId: a5fcd2082de5a9954dd16c6e6ca79aee4fcc865fbf49cdbeeb1275b60d06b35d
name: python-dependency-injector
arch: src
version: 4.41.0
epoch: 0
release: 1
summary: Dependency injection framework for Python
url: https://github.com/ets-labs/python-dependency-injector
rpm_license: BSD New
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-58cec383-352f-4046-b880-d7e5d343a8bb
location_href: 00009859-python-dependency-injector/python-dependency-injector-4.41.0-1.src.rpm
checksum_type: sha256
description:
  ``Dependency Injector`` is a dependency injection framework for Python.
  It helps implement the dependency injection principle.
  Key features of the ``Dependency Injector``:
  - **Providers**. Provides ``Factory``, ``Singleton``, ``Callable``, ``Coroutine``, ``Object``,
    ``List``, ``Dict``, ``Configuration``, ``Resource``, ``Dependency``, and ``Selector`` providers
    that help assemble your objects.
    See `Providers <https://python-dependency-injector.ets-labs.org/providers/index.html>`_.
  - **Overriding**. Can override any provider by another provider on the fly. This helps in testing
    and configuring dev/stage environment to replace API clients with stubs etc. See
    `Provider overriding <https://python-dependency-injector.ets-labs.org/providers/overriding.html>`_.
  - **Configuration**. Reads configuration from ``yaml``, ``ini``, and ``json`` files, ``pydantic`` settings,
    environment variables, and dictionaries.
    See `Configuration provider <https://python-dependency-injector.ets-labs.org/providers/configuration.html>`_.
  - **Resources**. Helps with initialization and configuring of logging, event loop, thread
    or process pool, etc. Can be used for per-function execution scope in tandem with wiring.
    See `Resource provider <https://python-dependency-injector.ets-labs.org/providers/resource.html>`_.
  - **Containers**. Provides declarative and dynamic containers.
    See `Containers <https://python-dependency-injector.ets-labs.org/containers/index.html>`_.
  - **Wiring**. Injects dependencies into functions and methods. Helps integrate with
    other frameworks: Django, Flask, Aiohttp, Sanic, FastAPI, etc.
    See `Wiring <https://python-dependency-injector.ets-labs.org/wiring.html>`_.
  - **Asynchronous**. Supports asynchronous injections.
    See `Asynchronous injections <https://python-dependency-injector.ets-labs.org/providers/async.html>`_.
  - **Typing**. Provides typing stubs, ``mypy``-friendly.
    See `Typing and mypy <https://python-dependency-injector.ets-labs.org/providers/typing_mypy.html>`_.
  - **Performance**. Fast. Written in ``Cython``.
  - **Maturity**. Mature and production-ready. Well-tested, documented, and supported.
     from dependency_injector import containers, providers
     from dependency_injector.wiring import Provide, inject
     class Container(containers.DeclarativeContainer):
         config = providers.Configuration()
         api_client = providers.Singleton(
             ApiClient,
             api_key=config.api_key,
             timeout=config.timeout,
         )
         service = providers.Factory(
             Service,
             api_client=api_client,
         )
     @inject
     def main(service: Service = Provide[Container.service]) -> None:
     if __name__ == "__main__":
         container = Container()
         container.config.api_key.from_env("API_KEY", required=True)
         container.config.timeout.from_env("TIMEOUT", as_=int, default=5)
         container.wire(modules=[__name__])
         main()  # <-- dependency is injected automatically
         with container.api_client.override(mock.Mock()):
             main()  # <-- overridden dependency is injected automatically
  When you call the ``main()`` function the ``Service`` dependency is assembled and injected automatically.
  When you do testing, you call the ``container.api_client.override()`` method to replace the real API
  client with a mock. When you call ``main()``, the mock is injected.
  You can override any provider with another provider.
  It also helps you in a re-configuring project for different environments: replace an API client
  with a stub on the dev or stage.
  With the ``Dependency Injector``, object assembling is consolidated in a container. Dependency injections are defined explicitly.
  This makes it easier to understand and change how an application works.
  Visit the docs to know more about the
  `Dependency injection and inversion of control in Python <https://python-dependency-injector.ets-labs.org/introduction/di_in_python.html>`_.


pkgId: 7e844a0f05a7358cbd2f1f3284e740c595b01c70f9c62f4b6e9fcd502f27ea81
name: python-dependency-injector-debuginfo
arch: aarch64
version: 4.41.0
epoch: 0
release: 1
summary: Debug information for package python-dependency-injector
url: https://github.com/ets-labs/python-dependency-injector
rpm_license: BSD New
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-58cec383-352f-4046-b880-d7e5d343a8bb
rpm_sourcerpm: python-dependency-injector-4.41.0-1.src.rpm
location_href: 00009859-python-dependency-injector/python-dependency-injector-debuginfo-4.41.0-1.aarch64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-dependency-injector.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: 31d80c2974e802f34c39569290fed6a4f79f918f86355cc95bba8aa76c05d27f
name: python-dependency-injector-debugsource
arch: aarch64
version: 4.41.0
epoch: 0
release: 1
summary: Debug sources for package python-dependency-injector
url: https://github.com/ets-labs/python-dependency-injector
rpm_license: BSD New
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-58cec383-352f-4046-b880-d7e5d343a8bb
rpm_sourcerpm: python-dependency-injector-4.41.0-1.src.rpm
location_href: 00009859-python-dependency-injector/python-dependency-injector-debugsource-4.41.0-1.aarch64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-dependency-injector.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: 1f92e128712da9ecaa944465b67247fd56020a5657ec6c7b1ba6dd4f047dc43f
name: python-deprecation
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: A library to handle automated deprecations
url: http://deprecation.readthedocs.io/
rpm_license: Apache 2
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c52c1712-094a-4dac-83d4-1e97887284e3
location_href: 00003417-python-deprecation/python-deprecation-2.1.0-1.src.rpm
checksum_type: sha256
description:
  The ``deprecation`` library provides a ``deprecated`` decorator and a
  ``fail_if_not_removed`` decorator for your tests. Together, the two
  enable the automation of several things:
  1. The docstring of a deprecated method gets the deprecation details
     appended to the end of it. If you generate your API docs direct
     from your source, you don't need to worry about writing your own
     notification. You also don't need to worry about forgetting to
     write it. It's done for you.
  2. Rather than having code live on forever because you only deprecated
     it but never actually moved on from it, you can have your tests
     tell you when it's time to remove the code. The ``@deprecated``
     decorator can be told when it's time to entirely remove the code,
     which causes ``@fail_if_not_removed`` to raise an ``AssertionError``,
     causing either your unittest or py.test tests to fail.
  See http://deprecation.readthedocs.io/ for the full documentation.


pkgId: 9560caf7ebd86b7bac76bcacfec09617b2168e476995ad13dbd1335b2c669bc5
name: python-descartes
arch: src
version: 1.1.0
epoch: 0
release: 1
summary: Use geometric objects as matplotlib paths and patches
url: http://bitbucket.org/sgillies/descartes/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6eaddad6-a14f-4bc4-b421-c8216db46b26
location_href: 00003418-python-descartes/python-descartes-1.1.0-1.src.rpm
checksum_type: sha256
description:
  Use Shapely_ or GeoJSON-like geometric objects as matplotlib paths and patches
  Requires: matplotlib, numpy, and optionally Shapely 1.2+.
  Example::
    from matplotlib import pyplot
    from shapely.geometry import LineString
    from descartes import PolygonPatch
    BLUE = '#6699cc'
    GRAY = '#999999'
    def plot_line(ax, ob):
        x, y = ob.xy
        ax.plot(x, y, color=GRAY, linewidth=3, solid_capstyle='round', zorder=1)
    line = LineString([(0, 0), (1, 1), (0, 2), (2, 2), (3, 1), (1, 0)])
    fig = pyplot.figure(1, figsize=(10, 4), dpi=180)
    
    ax = fig.add_subplot(121)
    plot_line(ax, line)
    dilated = line.buffer(0.5)
    patch1 = PolygonPatch(dilated, fc=BLUE, ec=BLUE, alpha=0.5, zorder=2)
    ax.add_patch(patch1)
    
    ax = fig.add_subplot(122)
    patch2a = PolygonPatch(dilated, fc=GRAY, ec=GRAY, alpha=0.5, zorder=1)
    ax.add_patch(patch2a)
    eroded = dilated.buffer(-0.3)
    
    polygon = eroded.__geo_interface__
    
    
    
    
    patch2b = PolygonPatch(polygon, fc=BLUE, ec=BLUE, alpha=0.5, zorder=2)
    ax.add_patch(patch2b)
    pyplot.show()
  See also: examples/patches.py.
  Descartes is not associated with the identically named and apparently defunct
  project at http://descartes.sourceforge.net/.


pkgId: 8e6aab3443ed6615eeb03b0203465777f629cd44f308bbd08cb13c7bf5b84271
name: python-devolo-home-control-api
arch: src
version: 0.18.2
epoch: 0
release: 1
summary: devolo Home Control API in Python
url: https://github.com/2Fake/devolo_home_control_api
rpm_license: GPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7e7a1047-2d30-4918-965b-ff0e5ce53984
location_href: 00003422-python-devolo-home-control-api/python-devolo-home-control-api-0.18.2-1.src.rpm
checksum_type: sha256
description:
  [![GitHub Workflow Status](https://img.shields.io/github/workflow/status/2Fake/devolo_home_control_api/Python%20package)](https://github.com/2Fake/devolo_home_control_api/actions?query=workflow%3A%22Python+package%22)
  [![PyPI - Downloads](https://img.shields.io/pypi/dd/devolo-home-control-api)](https://pypi.org/project/devolo-home-control-api/)
  [![Code Climate maintainability](https://img.shields.io/codeclimate/maintainability/2Fake/devolo_home_control_api)](https://codeclimate.com/github/2Fake/devolo_home_control_api)
  [![Coverage Status](https://coveralls.io/repos/github/2Fake/devolo_home_control_api/badge.svg?branch=master)](https://coveralls.io/github/2Fake/devolo_home_control_api?branch=master)

  This project implements parts of the devolo Home Control API in Python. It is based on reverse engineering and therefore may fail with any new devolo update. If you discover a breakage, please feel free to [report an issue](https://github.com/2Fake/devolo_home_control_api/issues).



  Defining the system requirements with exact versions typically is difficult. But there is a tested environment:

  * Linux
  * Python 3.7.12
  * pip 22.0.1
  * requests 2.27.1
  * websocket_client 1.3.1
  * zeroconf 0.38.4

  Other versions and even other operating systems might work. Feel free to tell us about your experience. If you want to run our unit tests, you also need:

  * pytest 7.0.1
  * pytest-mock 3.7.0



  In our versioning we follow [Semantic Versioning](https://semver.org/).



  The Python Package Index takes care for you. Just use pip.

  ```bash
  pip install devolo-home-control-api
  ```



  First, you need to get the sources.

  ```bash
  git clone git@github.com:2Fake/devolo_home_control_api.git
  ```

  Then you need to take care of the requirements.

  ```bash
  cd devolo_home_control_api
  python setup.py install
  ```

  If you want to run out tests, install the extra requirements and start pytest.

  ```bash
  pip install -e .[test]
  pytest
  ```



  To see that basic functionality, please look at our [small example](https://github.com/2Fake/devolo_home_control_api/blob/master/example.py). For this example, a working Home Control Central Unit must be attached to your my devolo account. After entering your my devolo username and password, simply run it:

  ```bash
  python3 example.py
  ```

  You will see changes to any BinarySwitch device (e.g. state or consumption) reported to your console. If the executing device is in the same LAN as the Home Control Central Unit, it will be discovered via Zeroconf. In this case, data will be collected from the Central Unit directly; otherwise data will be collected via cloud from my devolo.



  If you do not know your gateway ID, you can ask my devolo. For now, no other functionality is implemented, that you would need to access directly. If you discover other use cases, feel free to file a feature request.

  ```python
  mydevolo = Mydevolo.get_instance()
  mydevolo.user = "username"
  mydevolo.password = "password"
  for gateway_id in mydevolo.get_gateway_ids():
      print(gateway_id)
  ```



  There are two ways of getting data:

  1. Let the websocket push data into your object, but still poll the object
  1. Subscribe to the publisher and let it push (preferred)



  When using websocket events, messages will keep the object up to date. Nevertheless, no further action is triggered. So you have to ask yourself. The following example will list the current state of all binary switches. If the state changes, you will not notice unless you ask again.

  ```python
  homecontrol = HomeControl(gateway_id=gateway_id, mydevolo_instance=mydevolo)
  for binary_switch in mprm.binary_switch_devices:
      for state in binary_switch.binary_switch_property:
          print (f"State of {binary_switch.name} ({binary_switch.binary_switch_property[state].element_uid}): {binary_switch.binary_switch_property[state].state}")
  ```

  To execute this example, you again need a configured instance of Mydevolo.



  This preferred usage is shown in our [small example](https://github.com/2Fake/devolo_home_control_api/blob/master/example.py). On every websocket event, ```update()``` will be called. That way you can react to changes right away.



  You will find snippets discribing other use cases in our [wiki](https://github.com/2Fake/devolo_home_control_api/wiki).


pkgId: 71a2100c654c771cd07711cd87c52c0748b3591332ae0aa956ad5d8c33a81dab
name: python-dfdatetime
arch: src
version: 20230225
epoch: 0
release: 1
summary: Digital Forensics date and time (dfDateTime).
url: https://github.com/log2timeline/dfdatetime
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e6859668-7ee0-4819-ae5e-ae99091bae2d
location_href: 00003424-python-dfdatetime/python-dfdatetime-20230225-1.src.rpm
checksum_type: sha256
description:
  dfDateTime, or Digital Forensics date and time, provides date and time objects to preserve accuracy and precision.


pkgId: 3d2c22fbedcd1a8ba52657cc7261a74fbeac5d07fc0965bf803e43347583870d
name: python-dhooks
arch: src
version: 1.1.4
epoch: 0
release: 1
summary: An (a)sync wrapper for discord webhooks
url: https://github.com/4rqm/dhooks/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-791c1d1f-9a1f-40b9-9f23-ce961ab81ff8
location_href: 00010825-python-dhooks/python-dhooks-1.1.4-1.src.rpm
checksum_type: sha256
description:
  <h1 align="center">Discord Webhooks</h1>

  <div align="center">
    <strong><i>Interact with discord webhooks using python.</i></strong>
    <br>
    <br>

    <a href="https://travis-ci.com/kyb3r/dhooks">
      <img src="https://img.shields.io/travis/com/kyb3r/dhooks/master.svg?style=for-the-badge&colorB=06D6A0" alt="Travis" />
    </a>

    <a href="https://test-dhooks-doc.readthedocs.io/en/latest/?badge=latest">
      <img src="https://img.shields.io/readthedocs/dhooks.svg?style=for-the-badge&colorB=E8BE5D" alt="Documentation Status" />
    </a>

    <a href="https://github.com/kyb3r/dhooks/">
      <img src="https://img.shields.io/pypi/pyversions/dhooks.svg?style=for-the-badge&colorB=F489A3" alt="Py Versions" />
    </a>

    <a href="https://pypi.org/project/dhooks/">
      <img src="https://img.shields.io/pypi/v/dhooks.svg?style=for-the-badge&colorB=61829F" alt="PyPi" />
    </a>

    <a href="https://github.com/kyb3r/dhooks/blob/master/LICENSE">
      <img src="https://img.shields.io/github/license/kyb3r/dhooks.svg?style=for-the-badge&colorB=7289DA" alt="LICENSE" />
    </a>
  </div>
  <br>

  <div align="center">
    This <strong>simple</strong> library enables you to easily interact with discord webhooks, allowing you to easily format discord messages and discord embeds, retrieve webhook information, modify and delete webhooks. Asynchronous usage is also supported.
  </div>



  To install the library simply use pip.

  ```commandline
  pip install dhooks
  ```

  If you would also like to get the latest version of dhooks from GitHub, build docs, run tests or run examples, you may want to install
  dhooks with the optional extended dependencies.

  ```commandline
  git clone https://github.com/kyb3r/dhooks.git
  cd dhooks
  pip install .[tests,docs,examples]
  ```





  ```python
  from dhooks import Webhook

  hook = Webhook('url')

  hook.send("Hello there! I'm a webhook :open_mouth:")
  ```

  <img src='https://i.imgur.com/8wu283y.png' width=300>



  You can easily format and send embeds using this library.

  <img src='https://i.imgur.com/8Ms4OID.png' width=400>

  Note: `Embed` objects from `discord.py` are also compatible with this library.

  ```python
  from dhooks import Webhook, Embed

  hook = Webhook('url')

  embed = Embed(
      description='This is the **description** of the embed! :smiley:',
      color=0x5CDBF0,
      timestamp='now'  # sets the timestamp to current time
      )

  image1 = 'https://i.imgur.com/rdm3W9t.png'
  image2 = 'https://i.imgur.com/f1LOr4q.png'

  embed.set_author(name='Author Goes Here', icon_url=image1)
  embed.add_field(name='Test Field', value='Value of the field :open_mouth:')
  embed.add_field(name='Another Field', value='1234 :smile:')
  embed.set_footer(text='Here is my footer text', icon_url=image1)

  embed.set_thumbnail(image1)
  embed.set_image(image2)

  hook.send(embed=embed)
  ```



  You can easily send files as shown.

  ```python
  from dhooks import Webhook, File
  from io import BytesIO
  import requests

  hook = Webhook('url')

  file = File('path/to/file.png', name='cat.png')  # optional name for discord

  hook.send('Look at this:', file=file)
  ```

  You can also pass a file-like object:

  ```python
  response = requests.get('https://i.imgur.com/rdm3W9t.png')
  file = File(BytesIO(response.content), name='wow.png')

  hook.send('Another one:', file=file)
  ```



  You can get some basic information related to the webhook through Discord's API.

  ```python
  hook.get_info()
  ```

  The following attributes will be populated with data from discord:

  - `hook.guild_id`
  - `hook.channel_id`
  - `hook.default_name`
  - `hook.default_avatar_url`



  You can change the default name and avatar of a webhook easily.

  ```python
  with open('img.png', rb) as f:
      img = f.read()  # bytes

  hook.modify(name='Bob', avatar=img)

  hook.delete()  # webhook deleted permanently
  ```



  To asynchronously make requests using `aiohttp`, simply use `Webhook.Async` to create the object. An example is as follows. Simply use the `await` keyword when calling API methods.

  ```python
  from dhooks import Webhook

  async def main():
      hook = Webhook.Async('url')

      await hook.send('hello')
      await hook.modify('bob')
      await hook.get_info()
      await hook.delete()

      await hook.close()  # close the client session
  ```

  Alternatively you can use an `async with` block (asynchronous context manager) to automatically close the session once finished.

  ```python
  async def main():
      async with Webhook.Async('url') as hook:
          await hook.send('hello')
  ```



  You can find the full API reference [here](https://dhooks.readthedocs.io).



  This project is licensed under MIT.



  Feel free to contribute to this project, a helping hand is always appreciated.

  [Join our discord server](https://discord.gg/etJNHCQ).


pkgId: bc54d1dfa89323fe9200942d20997864775c9c820002ae636abc8acf13fca8d6
name: python-diagrams
arch: src
version: 0.23.3
epoch: 0
release: 1
summary: Diagram as Code
url: https://diagrams.mingrammer.com
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-8c44b123-76e9-4be3-94b5-6c5ad28f15ea
location_href: 00012811-python-diagrams/python-diagrams-0.23.3-1.src.rpm
checksum_type: sha256
description:
  ![diagrams logo](assets/img/diagrams.png)



  [![license](https://img.shields.io/badge/license-MIT-blue.svg)](/LICENSE)
  [![pypi version](https://badge.fury.io/py/diagrams.svg)](https://badge.fury.io/py/diagrams)
  ![python version](https://img.shields.io/badge/python-%3E%3D%203.6-blue?logo=python)
  ![Run tests](https://github.com/mingrammer/diagrams/workflows/Run%20tests/badge.svg?branch=master)
  [![todos](https://badgen.net/https/api.tickgit.com/badgen/github.com/mingrammer/diagrams?label=todos)](https://www.tickgit.com/browse?repo=github.com/mingrammer/diagrams)
  ![contributors](https://img.shields.io/github/contributors/mingrammer/diagrams)

  <a href="https://www.buymeacoffee.com/mingrammer" target="_blank"><img src="https://www.buymeacoffee.com/assets/img/custom_images/orange_img.png" alt="Buy Me A Coffee" style="height: 41px !important;width: 174px !important;box-shadow: 0px 3px 2px 0px rgba(190, 190, 190, 0.5) !important;" ></a>

  **Diagram as Code**.

  Diagrams lets you draw the cloud system architecture **in Python code**. It was born for **prototyping** a new system architecture design without any design tools. You can also describe or visualize the existing system architecture as well. Diagrams currently supports main major providers including: `AWS`, `Azure`, `GCP`, `Kubernetes`, `Alibaba Cloud`, `Oracle Cloud` etc... It also supports `On-Premise` nodes, `SaaS` and major `Programming` frameworks and languages.

  **Diagram as Code** also allows you to **track** the architecture diagram changes in any **version control** system.

  >  NOTE: It does not control any actual cloud resources nor does it generate cloud formation or terraform code. It is just for drawing the cloud system architecture diagrams.



  ![aws provider](https://img.shields.io/badge/AWS-orange?logo=amazon-aws&color=ff9900)
  ![azure provider](https://img.shields.io/badge/Azure-orange?logo=microsoft-azure&color=0089d6)
  ![gcp provider](https://img.shields.io/badge/GCP-orange?logo=google-cloud&color=4285f4)
  ![ibm provider](https://img.shields.io/badge/IBM-orange?logo=ibm&color=052FAD)
  ![kubernetes provider](https://img.shields.io/badge/Kubernetes-orange?logo=kubernetes&color=326ce5)
  ![alibaba cloud provider](https://img.shields.io/badge/AlibabaCloud-orange?logo=alibaba-cloud&color=ff6a00)
  ![oracle cloud provider](https://img.shields.io/badge/OracleCloud-orange?logo=oracle&color=f80000)
  ![openstack provider](https://img.shields.io/badge/OpenStack-orange?logo=openstack&color=da1a32)
  ![firebase provider](https://img.shields.io/badge/Firebase-orange?logo=firebase&color=FFCA28)
  ![digital ocean provider](https://img.shields.io/badge/DigitalOcean-0080ff?logo=digitalocean&color=0080ff)
  ![elastic provider](https://img.shields.io/badge/Elastic-orange?logo=elastic&color=005571)
  ![outscale provider](https://img.shields.io/badge/OutScale-orange?color=5f87bf)
  ![on premise provider](https://img.shields.io/badge/OnPremise-orange?color=5f87bf)
  ![generic provider](https://img.shields.io/badge/Generic-orange?color=5f87bf)
  ![programming provider](https://img.shields.io/badge/Programming-orange?color=5f87bf)
  ![saas provider](https://img.shields.io/badge/SaaS-orange?color=5f87bf)
  ![c4 provider](https://img.shields.io/badge/C4-orange?color=5f87bf)



  It requires **Python 3.6** or higher, check your Python version first.

  It uses [Graphviz](https://www.graphviz.org/) to render the diagram, so you need to [install Graphviz](https://graphviz.gitlab.io/download/) to use **diagrams**. After installing graphviz (or already have it), install the **diagrams**.

  > macOS users can download the Graphviz via `brew install graphviz` if you're using [Homebrew](https://brew.sh).

  ```shell

  $ pip install diagrams


  $ pipenv install diagrams


  $ poetry add diagrams
  ```

  You can start with [quick start](https://diagrams.mingrammer.com/docs/getting-started/installation#quick-start). Check out [guides](https://diagrams.mingrammer.com/docs/guides/diagram) for more details, and you can find all available nodes list in [here](https://diagrams.mingrammer.com/docs/nodes/aws).



  | Event Processing                                             | Stateful Architecture                                        | Advanced Web Service                                         |
  | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
  | ![event processing](https://diagrams.mingrammer.com/img/event_processing_diagram.png) | ![stateful architecture](https://diagrams.mingrammer.com/img/stateful_architecture_diagram.png) | ![advanced web service with on-premise](https://diagrams.mingrammer.com/img/advanced_web_service_with_on-premise.png) |

  You can find all the examples on the [examples](https://diagrams.mingrammer.com/docs/getting-started/examples) page.



  To contribute to diagram, check out [contribution guidelines](CONTRIBUTING.md).

  > Let me know if you are using diagrams! I'll add you in showcase page. (I'm working on it!) :)



  [GitPitch](https://gitpitch.github.io/gitpitch) is the perfect slide deck solution for Tech Conferences, Training, Developer Advocates, and Educators. Diagrams is now available as a dedicated [Cloud Diagram Markdown Widget](https://gitpitch.github.io/gitpitch/#/diagrams/cloud-architecture) so you can use Diagrams directly on any slide for conferences, meetups, and training.

  [Cloudiscovery](https://github.com/Cloud-Architects/cloudiscovery) helps you to analyze resources in your cloud (AWS/GCP/Azure/Alibaba/IBM) account. It allows you to create a diagram of analyzed cloud resource map based on this Diagrams library, so you can draw your existing cloud infrastructure with Cloudiscovery.

  [Airflow Diagrams](https://github.com/feluelle/airflow-diagrams) is an Airflow plugin that aims to easily visualise your Airflow DAGs on service level from providers like AWS, GCP, Azure, etc. via diagrams.



  - If you are familiar with Go, you can use [go-diagrams](https://github.com/blushft/go-diagrams) as well.



  [MIT](LICENSE)


pkgId: 1dd063a8da3f4ed5c2abcc66466d7a730b4aa6d15fe5bb0c2013518df2dffdf5
name: python-dictdumper
arch: src
version: 0.8.4.post2
epoch: 0
release: 1
summary: Python dict formatted dumper.
url: https://github.com/JarryShaw/dictdumper#dictdumper
rpm_license: BSD 3-Clause License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d8d25a68-e4d9-4d93-9fd4-de5729c2b40a
location_href: 00003428-python-dictdumper/python-dictdumper-0.8.4.post2-1.src.rpm
checksum_type: sha256
description:
  &emsp; Currently, it supports following formats --
   - `dictdumper.Dumper` -- abstract base class of all dumpers
   - `dictdumper.JSON` -- dump JavaScript object notation (`JSON`) format file
   - `dictdumper.PLIST` -- dump Apple property list (`PLIST`) format file
   - `dictdumper.Tree` -- dump tree-view text (`TXT`) format file
   - `dictdumper.XML` -- dump extensible markup language (`XML`) file (__base class__)
   - `dictdumper.HTML` -- dump JavaScript file under `Vue.js` framework (__DEPRECATED__)
  ![](https://github.com/JarryShaw/dictdumper/blob/master/doc/dictdumper.png)
  &nbsp;

  > Note that `dictdumper` supports Python versions __2.7__ and all versions __since 3.0__
  ```
  pip install dictdumper
  ```
  &nbsp;

  &emsp; `dictdumper` is quite easy to use. After installation, importation, and initialisation, you can simple call the instance to dump contents.
  > Take `dictdumper.Tree` for example
  ```python
  import dictdumper
  dumper = dictdumper.Tree('out.txt')
  test_1 = dict(
      foo=-1,
      bar='Hello, world!',
      boo=dict(
          foo_again=True,
          bar_again=memoryview(b'bytes'),
          boo_again=None,
      ),
  )
  dumper(test_1, name='test_1')
  ```
  ```
  $ cat out.txt
  test_1
    |-- foo -> -1
    |-- bar -> Hello, world!
    |-- boo
          |-- foo_again -> True
          |-- bar_again
          |     |-- type -> memoryview
          |     |-- value -> 62 79 74 65 73
          |     |-- text -> bytes
          |-- boo_again -> NIL
  ```
  ```python
  import datetime
  test_2 = dict(
      foo=[1, 2.0, 3],
      bar=(1.0, bytearray(b'a long long bytes'), 3.0),
      boo=dict(
          foo_again=b'bytestring',
          bar_again=datetime.datetime(2020, 1, 31, 20, 15, 10, 163010),
          boo_again=float('-inf'),
      ),
  )
  dumper(test_2, name='test_2')
  ```
  ```
  $ cat out.txt
  test_1
    |-- foo -> -1
    |-- bar -> Hello, world!
    |-- boo
          |-- foo_again -> True
          |-- bar_again
          |     |-- type -> memoryview
          |     |-- value -> 62 79 74 65 73
          |     |-- text -> bytes
          |-- boo_again -> NIL
  test_2
    |-- foo
    |     |--> 1
    |     |--> 2.0
    |     |--> 3
    |-- bar
    |     |-- type -> tuple
    |     |-- value
    |           |--> 1.0
    |           |--> --
    |           |     |-- type -> bytearray
    |           |     |-- value
    |           |     |     |--> 61 20 6c 6f 6e 67 20 6c 6f 6e 67 20 62 79 74 65
    |           |     |          73
    |           |     |-- text -> a long long bytes
    |           |--> 3.0
    |-- boo
          |-- foo_again -> 62 79 74 65 73 74 72 69 6e 67
          |-- bar_again -> 2020-01-31T20:15:10.163010
          |-- boo_again -> -Infinity
  ```
  ```python
  test_3 = dict(
      foo="stringstringstringstringstringstringstringstringstringstring",
      bar=[
          "s1", False, "s3",
      ],
      boo=[
          "s4", dict(s="5", j="5"), "s6"
      ],
      far=dict(
          far_foo=["s1", "s2", "s3"],
          far_var="s4",
      ),
      biu=float('nan'),
  )
  dumper(test_3, name='test_3')
  ```
  ```
  $ cat out.txt
  test_1
    |-- foo -> -1
    |-- bar -> Hello, world!
    |-- boo
          |-- foo_again -> True
          |-- bar_again
          |     |-- type -> memoryview
          |     |-- value -> 62 79 74 65 73
          |     |-- text -> bytes
          |-- boo_again -> NIL
  test_2
    |-- foo
    |     |--> 1
    |     |--> 2.0
    |     |--> 3
    |-- bar
    |     |-- type -> tuple
    |     |-- value
    |           |--> 1.0
    |           |--> --
    |           |     |-- type -> bytearray
    |           |     |-- value
    |           |     |     |--> 61 20 6c 6f 6e 67 20 6c 6f 6e 67 20 62 79 74 65
    |           |     |          73
    |           |     |-- text -> a long long bytes
    |           |--> 3.0
    |-- boo
          |-- foo_again -> 62 79 74 65 73 74 72 69 6e 67
          |-- bar_again -> 2020-01-31T20:15:10.163010
          |-- boo_again -> -Infinity
  test_3
    |-- foo
    |     |--> stringstringstringstringstringstringstri
    |          ngstringstringstring
    |-- bar
    |     |--> s1
    |     |--> False
    |     |--> s3
    |-- boo
    |     |--> s4
    |     |--> --
    |     |     |-- s -> 5
    |     |     |-- j -> 5
    |     |--> s6
    |-- far
    |     |-- far_foo
    |     |     |--> s1
    |     |     |--> s2
    |     |     |--> s3
    |     |-- far_var -> s4
    |-- biu -> NaN
  ```


pkgId: 737b53f24e18a50e598b9291664f1d4cd57a42d660437fdb545d61a67bd39f7c
name: python-dictor
arch: src
version: 0.1.11
epoch: 0
release: 1
summary: an elegant dictionary and JSON handler
url: https://github.com/perfecto25/dictor
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ce346a90-0bb1-436c-917b-7540980def0d
location_href: 00012055-python-dictor/python-dictor-0.1.11-1.src.rpm
checksum_type: sha256
description:
      pip install dictor

  sample.json
  ```json
  {
    "characters": {
      "Lonestar": {
        "id": 55923,
        "role": "renegade",
        "items": ["space winnebago", "leather jacket"]
      },
      "Barfolomew": {
        "id": 55924,
        "role": "mawg",
        "items": ["peanut butter jar", "waggy tail"]
      },
      "Dark Helmet": {
        "id": 99999,
        "role": "Good is dumb",
        "items": ["Shwartz", "helmet"]
      },
      "Skroob": {
        "id": 12345,
        "role": "Spaceballs CEO",
        "items": ["luggage"]
      }
    }
  }
  ```
  now lets get info on all Characters
  ```python
  from dictor import dictor
  with open('sample.json') as data:
      data = json.load(data)
  print(dictor(data, 'characters'))
  {u'Lonestar': {u'items': [u'space winnebago', u'leather jacket'], u'role': u'renegade', u'id': 55923}, u'Dark Helmet': {u'items': [u'Shwartz', u'helmet'], u'role': u'Good is dumb', u'id': 99999}, u'Barfolomew': {u'items': [u'peanut butter jar', u'waggy tail'], u'role': u'mawg', u'id': 55924}, u'Skroob': {u'items': [u'luggage'], u'role': u'Spaceballs CEO', u'id': 12345}}


pkgId: c85a3178ec6d5f35d4b428d9d85ea8cd49a33d53a4f6d3d72e6c673fadcf6ec3
name: python-dicttoxml
arch: src
version: 1.7.16
epoch: 0
release: 1
summary: Converts a Python dictionary or other native data type into a valid XML string.
description: Converts a Python dictionary or other native data type into a valid XML string.
url: https://github.com/quandyfactory/dicttoxml
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-3841bb4f-f187-4633-9134-e44838e1d631
location_href: 00003429-python-dicttoxml/python-dicttoxml-1.7.16-1.src.rpm
checksum_type: sha256
rpm_license:
  GNU GENERAL PUBLIC LICENSE  Version 2, June 1991  Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA  Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.  Preamble  The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.  When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.  To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.  For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.  We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.  Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.  Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.  The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION  0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".  Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.  1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.  You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.  2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:  a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)  These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.  Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.  In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.  3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:  a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)  The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.  If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.  4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.  5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.  6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.  7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.  If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.  It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.  This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.  8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.  9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.  Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.  10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.  NO WARRANTY  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.


pkgId: 3e4d393cbb48d5b7000365abf545232beb837ee97d880d0070673ae69c2886c8
name: python-diff-cover
arch: src
version: 7.5.0
epoch: 0
release: 1
summary: Run coverage and linting reports on diffs
url: https://github.com/Bachmann1234/diff-cover
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-8c2963b5-0bbe-48d1-8c60-c70166f06c79
location_href: 00003431-python-diff-cover/python-diff-cover-7.5.0-1.src.rpm
checksum_type: sha256
description:
  Automatically find diff lines that need test coverage.
  Also finds diff lines that have violations (according to tools such
  as pycodestyle, pyflakes, flake8, or pylint).
  This is used as a code quality metric during code reviews.


pkgId: 6d7c2209ccbd4ee880b16a6461bc6915c2993706bc2e29b92917ce5ca34995b8
name: python-diff-match-patch
arch: src
version: 20200713
epoch: 0
release: 1
url: https://github.com/diff-match-patch-python/diff-match-patch
rpm_license: Apache
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-735ff223-8f07-4acf-a965-2c759129d942
location_href: 00003432-python-diff-match-patch/python-diff-match-patch-20200713-1.src.rpm
checksum_type: sha256
summary:
  Repackaging of Google's Diff Match and Patch libraries. Offers robust algorithms to perform the operations required for synchronizing plain text.

description:
  Google's [Diff Match and Patch][DMP] library, packaged for modern Python.

  [![build status](https://travis-ci.org/diff-match-patch-python/diff-match-patch.svg?branch=master)](https://travis-ci.org/diff-match-patch-python/diff-match-patch)
  [![version](https://img.shields.io/pypi/v/diff-match-patch.svg)](https://pypi.org/project/diff-match-patch)
  [![license](https://img.shields.io/pypi/l/diff-match-patch.svg)](https://github.com/diff-match-patch-python/diff-match-patch/blob/master/LICENSE)



  diff-match-patch is supported on Python 2.7 or Python 3.4 or newer.
  You can install it from PyPI:

  ```shell
  python -m pip install diff-match-patch
  ```



  Generating a patchset (analogous to unified diff) between two texts:

  ```python
  from diff_match_patch import diff_match_patch

  dmp = diff_match_patch()
  patches = dmp.patch_make(text1, text2)
  diff = dmp.patch_toText(patches)
  ```

  Applying a patchset to a text can then be done with:

  ```python
  from diff_match_patch import diff_match_patch

  dmp = diff_match_patch()
  patches = dmp.patch_fromText(diff)
  new_text, _ = dmp.patch_apply(patches, text)
  ```


  The Diff Match and Patch libraries offer robust algorithms to perform the
  operations required for synchronizing plain text.

  1. Diff:
     * Compare two blocks of plain text and efficiently return a list of differences.
     * [Diff Demo](https://neil.fraser.name/software/diff_match_patch/demos/diff.html)
  2. Match:
     * Given a search string, find its best fuzzy match in a block of plain text. Weighted for both accuracy and location.
     * [Match Demo](https://neil.fraser.name/software/diff_match_patch/demos/match.html)
  3. Patch:
     * Apply a list of patches onto plain text. Use best-effort to apply patch even when the underlying text doesn't match.
     * [Patch Demo](https://neil.fraser.name/software/diff_match_patch/demos/patch.html)

  Originally built in 2006 to power Google Docs, this library is now available in C++, C#, Dart, Java, JavaScript, Lua, Objective C, and Python.



  * [API](https://github.com/google/diff-match-patch/wiki/API) - Common API across all languages.
  * [Line or Word Diffs](https://github.com/google/diff-match-patch/wiki/Line-or-Word-Diffs) - Less detailed diffs.
  * [Plain Text vs. Structured Content](https://github.com/google/diff-match-patch/wiki/Plain-Text-vs.-Structured-Content) - How to deal with data like XML.
  * [Unidiff](https://github.com/google/diff-match-patch/wiki/Unidiff) - The patch serialization format.
  * [Support](https://groups.google.com/forum/#!forum/diff-match-patch) - Newsgroup for developers.


  Although each language port of Diff Match Patch uses the same API, there are some language-specific notes.

  * [C++](https://github.com/google/diff-match-patch/wiki/Language:-Cpp)
  * [C#](https://github.com/google/diff-match-patch/wiki/Language:-C%23)
  * [Dart](https://github.com/google/diff-match-patch/wiki/Language:-Dart)
  * [Java](https://github.com/google/diff-match-patch/wiki/Language:-Java)
  * [JavaScript](https://github.com/google/diff-match-patch/wiki/Language:-JavaScript)
  * [Lua](https://github.com/google/diff-match-patch/wiki/Language:-Lua)
  * [Objective-C](https://github.com/google/diff-match-patch/wiki/Language:-Objective-C)
  * [Python](https://github.com/google/diff-match-patch/wiki/Language:-Python)

  A standardized speed test tracks the [relative performance of diffs](https://docs.google.com/spreadsheets/d/1zpZccuBpjMZTvL1nGDMKJc7rWL_m_drF4XKOJvB27Kc/edit#gid=0) in each language.


  This library implements [Myer's diff algorithm](https://neil.fraser.name/writing/diff/myers.pdf) which is generally considered to be the best general-purpose diff. A layer of [pre-diff speedups and post-diff cleanups](https://neil.fraser.name/writing/diff/) surround the diff algorithm, improving both performance and output quality.

  This library also implements a [Bitap matching algorithm](https://neil.fraser.name/writing/patch/bitap.ps) at the heart of a [flexible matching and patching strategy](https://neil.fraser.name/writing/patch/).

  [DMP]: https://github.com/google/diff-match-patch
  [API]: https://github.com/google/diff-match-patch/wiki/API


pkgId: 3428e6805f19fbc9b1dd86ee7ddeebb9c6650d122c64ae1a3eb8cec9defcc872
name: python-dijitso
arch: src
version: 2017.1.0
epoch: 0
release: 1
summary: Distributed just-in-time building of shared libraries
url: https://bitbucket.org/fenics-project/dijitso/
rpm_license: GNU Lesser General Public License v3 or later (LGPLv3+)
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f53b3b6e-5db2-4cdc-a7f1-8753b0d610dd
location_href: 00003434-python-dijitso/python-dijitso-2017.1.0-1.src.rpm
checksum_type: sha256
description:
  *A Python module for distributed just-in-time shared library building*
  Authors:
  - Martin Sandve Alnæs (martinal@simula.no)
  - Garth N. Wells (gnw20@cam.ac.uk)
  - Johannes Ring (johannr@simula.no)
  Contributors:
  - Jan Blechta (blechta@karlin.mff.cuni.cz)


pkgId: 9c028f3f60ede7e43e7cbcf33477506ce4de3ee727573e3e85b9278129838e3c
name: python-dingz
arch: src
version: 0.5.0
epoch: 0
release: 1
summary: Python API for interacting with Dingz devices
url: https://github.com/home-assistant-ecosystem/python-dingz
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9c435095-7c62-4afe-945e-d1e2b529b28d
location_href: 00003436-python-dingz/python-dingz-0.5.0-1.src.rpm
checksum_type: sha256
description:
  Python API for interacting with `Dingz <https://dingz.ch>`_ devices.
  This module is not official, developed, supported or endorsed by iolo AG or
  myStrom AG. For questions and other inquiries, use the issue tracker in this
  repository please.
  Without the support of iolo AG and myStrom AG it would have taken much longer
  to create this module which is the base for the integration into
  `Home Assistant <https://home-assistant.io>`_. Both companies have provided
  and are still providing hardware, valuable feedback and advice. Their
  continuous support make further development of this module possible.
  See `api.dingz.ch <https://api.dingz.ch/>`_ for the API details.


pkgId: 88f2f524ae87f644b60f9cb3a516394bd52e051e2a85c11cccc7b37b385c5dc1
name: python-dirq
arch: src
version: 1.8
epoch: 0
release: 1
summary: Directory based queue
url: https://github.com/cern-mig/python-dirq
rpm_license: ASL 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-292f610a-3f67-41e4-8b90-2fd9ab0106b9
location_href: 00003439-python-dirq/python-dirq-1.8-1.src.rpm
checksum_type: sha256
description:
  A port of Perl module Directory::Queue
  http://search.cpan.org/dist/Directory-Queue/

  The goal of this module is to offer a queue system using the underlying
  filesystem for storage, security and to prevent race conditions via atomic
  operations. It focuses on simplicity, robustness and scalability.

  This module allows multiple concurrent readers and writers to interact with
  the same queue.


pkgId: b4676a0d3523e0f03cf208e9d4a32bd9db07704e86fd3f39916864338ebbc9ee
name: python-discord-webhook
arch: src
version: 1.1.0
epoch: 0
release: 1
summary: execute discord webhooks
url: https://github.com/lovvskillz/python-discord-webhook
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4d697415-a48d-4d62-a610-7f265080888d
location_href: 00009235-python-discord-webhook/python-discord-webhook-1.1.0-1.src.rpm
checksum_type: sha256
description:
  [![GitHub license](https://img.shields.io/badge/license-MIT-brightgreen.svg)](https://raw.githubusercontent.com/lovvskillz/python-discord-webhook/master/LICENSE)
  [![PyPI version](https://badge.fury.io/py/discord-webhook.svg)](https://badge.fury.io/py/discord-webhook)
  [![Downloads](https://pepy.tech/badge/discord-webhook)](https://pepy.tech/project/discord-webhook)

  Execute Discord Webhooks (also has [async support](#async-support))



  Install via pip:
  ```
  pip install discord-webhook
  ```



  * [Basic Webhook](#basic-webhook)
  * [Create Multiple Instances / Use multiple URLs](#create-multiple-instances)
  * [Manage Being Rate Limited](#manage-being-rate-limited)
  * [Embedded Content](#webhook-with-embedded-content)
  * [Edit Webhook Message](#edit-webhook-messages)
  * [Delete Webhook Message](#delete-webhook-messages)
  * [Send Files](#send-files)
  * [Remove Embeds and Files](#remove-embeds-and-files)
  * [Allowed Mentions](#allowed-mentions)
  * [Use Proxies](#use-proxies)
  * [Timeout](#timeout)
  * [Async Support](#async-support)



  ```python
  from discord_webhook import DiscordWebhook

  webhook = DiscordWebhook(url='your webhook url', content='Webhook Message')
  response = webhook.execute()
  ```


  If you want to use multiple URLs you need to create multiple instances.

  ```python
  from discord_webhook import DiscordWebhook


  webhook1, webhook2 = DiscordWebhook.create_batch(urls=['first url', 'second url'], content='Webhook Message')
  response1 = webhook1.execute()
  response2 = webhook2.execute()
  ```
  ![Image](img/multiple_urls.png "Multiple Urls Result")



  ```python
  from discord_webhook import DiscordWebhook




  webhook = DiscordWebhook(url='your webhook url', rate_limit_retry=True,
                           content='Webhook Message')
  response = webhook.execute()
  ```

  ![Image](img/basic_webhook.png "Basic Example Result")



  ```python
  from discord_webhook import DiscordWebhook, DiscordEmbed

  webhook = DiscordWebhook(url='your webhook url')



  embed = DiscordEmbed(title='Your Title', description='Lorem ipsum dolor sit', color='03b2f8')


  webhook.add_embed(embed)

  response = webhook.execute()
  ```

  ![Image](img/simple_embed.png "Basic Embed Example Result")

  ```python
  from discord_webhook import DiscordWebhook, DiscordEmbed

  webhook = DiscordWebhook(url='your webhook url')


  embed = DiscordEmbed(title='Your Title', description='Lorem ipsum dolor sit', color='03b2f8')


  embed.set_author(name='Author Name', url='author url', icon_url='author icon url')


  embed.set_image(url='your image url')


  embed.set_thumbnail(url='your thumbnail url')


  embed.set_footer(text='Embed Footer Text', icon_url='URL of icon')


  embed.set_timestamp()


  embed.add_embed_field(name='Field 1', value='Lorem ipsum')
  embed.add_embed_field(name='Field 2', value='dolor sit')


  webhook.add_embed(embed)

  response = webhook.execute()
  ```

  ![Image](img/extended_embed.png "Basic Embed Example Result")

  This is another example with embedded content

  ```python
  from discord_webhook import DiscordWebhook, DiscordEmbed

  webhook = DiscordWebhook(url='your webhook url', username="New Webhook Username")

  embed = DiscordEmbed(title='Embed Title', description='Your Embed Description', color='03b2f8')
  embed.set_author(name='Author Name', url='https://github.com/lovvskillz', icon_url='https://avatars0.githubusercontent.com/u/14542790')
  embed.set_footer(text='Embed Footer Text')
  embed.set_timestamp()
  embed.add_embed_field(name='Field 1', value='Lorem ipsum')
  embed.add_embed_field(name='Field 2', value='dolor sit')
  embed.add_embed_field(name='Field 3', value='amet consetetur')
  embed.add_embed_field(name='Field 4', value='sadipscing elitr')

  webhook.add_embed(embed)
  response = webhook.execute()
  ```

  ![Image](img/extended_embed2.png "Example Embed Result")

  By Default, the Embed fields are placed side by side. We can arrange them in a new line by setting `inline=False` as follows:

  ```python
  from discord_webhook import DiscordWebhook, DiscordEmbed

  webhook = DiscordWebhook(url="your webhook url", username="New Webhook Username")

  embed = DiscordEmbed(
      title="Embed Title", description="Your Embed Description", color='03b2f8'
  )
  embed.set_author(
      name="Author Name",
      url="https://github.com/lovvskillz",
      icon_url="https://avatars0.githubusercontent.com/u/14542790",
  )
  embed.set_footer(text="Embed Footer Text")
  embed.set_timestamp()

  embed.add_embed_field(name="Field 1", value="Lorem ipsum", inline=False)
  embed.add_embed_field(name="Field 2", value="dolor sit", inline=False)
  embed.add_embed_field(name="Field 3", value="amet consetetur")
  embed.add_embed_field(name="Field 4", value="sadipscing elitr")

  webhook.add_embed(embed)
  response = webhook.execute()
  ```

  ![Image](img/extended_embed3.png "Example Non-Inline Embed Result")



  ```python
  from discord_webhook import DiscordWebhook
  from time import sleep

  webhook = DiscordWebhook(url='your webhook url', content='Webhook content before edit')
  webhook.execute()
  webhook.content = 'After Edit'
  sleep(10)
  webhook.edit()
  ```



  ```python
  from discord_webhook import DiscordWebhook
  from time import sleep

  webhook = DiscordWebhook(url='your webhook url', content='Webhook Content')
  webhook.execute()
  sleep(10)
  webhook.delete()
  ```



  ```python
  from discord_webhook import DiscordWebhook

  webhook = DiscordWebhook(url='your webhook url', username="Webhook with files")


  with open("path/to/first/image.jpg", "rb") as f:
      webhook.add_file(file=f.read(), filename='example.jpg')
  with open("path/to/second/image.jpg", "rb") as f:
      webhook.add_file(file=f.read(), filename='example2.jpg')

  response = webhook.execute()
  ```

  ![Image](img/webhook_files.png "Example Files Result")

  You can use uploaded attachments in Embeds:

  ```python
  from discord_webhook import DiscordWebhook, DiscordEmbed

  webhook = DiscordWebhook(url='your webhook url')

  with open("path/to/image.jpg", "rb") as f:
      webhook.add_file(file=f.read(), filename='example.jpg')

  embed = DiscordEmbed(title='Embed Title', description='Your Embed Description', color='03b2f8')
  embed.set_thumbnail(url='attachment://example.jpg')

  webhook.add_embed(embed)
  response = webhook.execute()
  ```



  ```python
  from discord_webhook import DiscordWebhook, DiscordEmbed

  webhook = DiscordWebhook(url='your webhook url')

  with open("path/to/image.jpg", "rb") as f:
      webhook.add_file(file=f.read(), filename='example.jpg')

  embed = DiscordEmbed(title='Embed Title', description='Your Embed Description', color='03b2f8')
  embed.set_thumbnail(url='attachment://example.jpg')

  webhook.add_embed(embed)
  response = webhook.execute(remove_embeds=True)


  ```

  `.remove_file()` removes the given file

  ```python
  from discord_webhook import DiscordWebhook

  webhook = DiscordWebhook(url='your webhook url', username="Webhook with files")


  with open("path/to/first/image.jpg", "rb") as f:
      webhook.add_file(file=f.read(), filename='example.jpg')
  with open("path/to/second/image.jpg", "rb") as f:
      webhook.add_file(file=f.read(), filename='example2.jpg')

  webhook.remove_file('example.jpg')

  response = webhook.execute()
  ```



  Look into the [Discord Docs](https://discord.com/developers/docs/resources/channel#allowed-mentions-object) for examples and for more explanation

  This example would only ping user `123` and `124` but not everyone else.

  ```python
  from discord_webhook import DiscordWebhook

  content = "@everyone say hello to our new friends <@123> and <@124>"
  allowed_mentions = {
      "users": ["123", "124"]
  }

  webhook = DiscordWebhook(url='your webhook url', content=content, allowed_mentions=allowed_mentions)
  response = webhook.execute()
  ```



  ```python
  from discord_webhook import DiscordWebhook

  proxies = {
    'http': 'http://10.10.1.10:3128',
    'https': 'http://10.10.1.10:1080',
  }
  webhook = DiscordWebhook(url='your webhook url', content='Webhook Message', proxies=proxies)
  response = webhook.execute()
  ```
  or
  ```python
  from discord_webhook import DiscordWebhook

  proxies = {
    'http': 'http://10.10.1.10:3128',
    'https': 'http://10.10.1.10:1080',
  }
  webhook = DiscordWebhook(url='your webhook url', content='Webhook Message')
  webhook.set_proxies(proxies)
  response = webhook.execute()
  ```



  ```
  usage: discord_webhook [-h] -u URL [URL ...] -c CONTENT [--username USERNAME]
                         [--avatar_url AVATAR_URL]

  Trigger discord webhook(s).

  optional arguments:
    -h, --help            show this help message and exit
    -u URL [URL ...], --url URL [URL ...]
                          Webhook(s) url(s)
    -c CONTENT, --content CONTENT
                          Message content
    --username USERNAME   override the default username of the webhook
    --avatar_url AVATAR_URL
                          override the default avatar of the webhook
  ```



  ```python
  from requests.exceptions import Timeout
  from discord_webhook import DiscordWebhook, DiscordEmbed


  webhook = DiscordWebhook(url='your webhook url', timeout=0.1)




  embed = DiscordEmbed(title='Embed Title', description='Your Embed Description', color='03b2f8')

  webhook.add_embed(embed)


  try:
      response = webhook.execute()
  except Timeout as err:
      print(f'Oops! Connection to Discord timed out: {err}')
  ```


  In order to use the async version, you need to install the package using:
  ```
  pip install discord-webhook[async]
  ```
  Example usage:
  ```python
  import asyncio
  from discord_webhook import AsyncDiscordWebhook


  async def send_webhook(message):
      webhook = AsyncDiscordWebhook(url='your webhook url', content=message)
      await webhook.execute()


  async def main():
      await asyncio.gather(
          send_webhook('Async webhook message 1'),
          send_webhook('Async webhook message 2'),
      )  # sends both messages asynchronously


  asyncio.run(main())
  ```




  This project uses [Poetry](https://python-poetry.org/docs/) for dependency management and packaging.

  Install Poetry and add Poetry to [Path](https://python-poetry.org/docs/#installation).

  **Debian / Ubuntu / Mac**

  `curl -sSL https://install.python-poetry.org | python3 -`

  **Windows**

  open powershell and run: `(Invoke-WebRequest -Uri https://install.python-poetry.org -UseBasicParsing).Content | py -`

  Install dependencies: `poetry install`

  Install the defined pre-commit hooks: `poetry run pre-commit install`

  Activate the virtualenv: `poetry shell`


pkgId: 6bd0fb6b8097cb99b7d2ff1a8436fea99adedc56f38c5dea9d3f6196e14e1579
name: python-discord.py-self
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: A Python wrapper for the Discord user API
url: https://github.com/dolfies/discord.py-self
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-41f558e8-e9fd-42aa-b374-2dcf9a18a357
location_href: 00011677-python-discord-py-self/python-discord.py-self-2.0.0-1.src.rpm
checksum_type: sha256
description:
  A modern, easy to use, feature-rich, and async ready API wrapper for Discord's user API written in Python.
  | **Note:**
  | Automating user accounts is against the Discord ToS. This library is a proof of concept and I cannot recommend using it. Do so at your own risk.


pkgId: 26f7e999d4a10bd799b0d3eb23c64356c2ae914bd6aca7266f8d505b3f0abaf9
name: python-diskcache
arch: src
version: 5.4.0
epoch: 0
release: 1
summary: Disk Cache -- Disk and file backed persistent cache.
url: http://www.grantjenks.com/docs/diskcache/
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c1b6a08a-1b01-4528-8533-c4660903cc02
location_href: 00003441-python-diskcache/python-diskcache-5.4.0-1.src.rpm
checksum_type: sha256
description:
  `DiskCache`_ is an Apache2 licensed disk and file backed cache library, written
  in pure-Python, and compatible with Django.
  The cloud-based computing of 2021 puts a premium on memory. Gigabytes of empty
  space is left on disks as processes vie for memory. Among these processes is
  Memcached (and sometimes Redis) which is used as a cache. Wouldn't it be nice
  to leverage empty disk space for caching?
  Django is Python's most popular web framework and ships with several caching
  backends. Unfortunately the file-based cache in Django is essentially
  broken. The culling method is random and large caches repeatedly scan a cache
  directory which slows linearly with growth. Can you really allow it to take
  sixty milliseconds to store a key in a cache with a thousand items?
  In Python, we can do better. And we can do it in pure-Python!
     In [1]: import pylibmc
     In [2]: client = pylibmc.Client(['127.0.0.1'], binary=True)
     In [3]: client[b'key'] = b'value'
     In [4]: %timeit client[b'key']
     10000 loops, best of 3: 25.4 µs per loop
     In [5]: import diskcache as dc
     In [6]: cache = dc.Cache('tmp')
     In [7]: cache[b'key'] = b'value'
     In [8]: %timeit cache[b'key']
     100000 loops, best of 3: 11.8 µs per loop
  **Note:** Micro-benchmarks have their place but are not a substitute for real
  measurements. DiskCache offers cache benchmarks to defend its performance
  claims. Micro-optimizations are avoided but your mileage may vary.
  DiskCache efficiently makes gigabytes of storage space available for
  caching. By leveraging rock-solid database libraries and memory-mapped files,
  cache performance can match and exceed industry-standard solutions. There's no
  need for a C compiler or running another process. Performance is a feature and
  testing has 100% coverage with unit tests and hours of stress.


pkgId: 8503b8ce6fc2f4661d967f97502f3fa294c19257f5a6da9dbc3627182bff8020
name: python-distconfig
arch: src
version: 0.1.0
epoch: 0
release: 1
summary: Library to manage configuration using Zookeeper, Etcd, Consul
url: http://github.com/deliveryhero/distconfig/
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9f0693e3-dd7a-4ec8-a5f9-2d55b94a91e5
location_href: 00012173-python-distconfig/python-distconfig-0.1.0-1.src.rpm
checksum_type: sha256
description:
  Library to manage distributed configuration using either `ZooKeeper <https://zookeeper.apache.org/>`_ or
  `Etcd <https://github.com/coreos/etcd>`_ or `Consul <http://www.consul.io/>`_.


pkgId: f5241c8dec9a50b9e90b281f2d641bb4ce62bb34b4c91b1f6d90dfc9d9617c36
name: python-distributed
arch: src
version: 2023.3.2.1
epoch: 0
release: 1
summary: Distributed scheduler for Dask
url: https://distributed.dask.org
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c5c0c547-75eb-440d-8973-651ab5f0b31e
location_href: 00009104-python-distributed/python-distributed-2023.3.2.1-1.src.rpm
checksum_type: sha256
description:
  |Test Status| |Longitudinal Report (full)| |Longitudinal Report (short)| |Coverage| |Doc Status| |Discourse| |Version Status| |NumFOCUS|
  A library for distributed computation.  See documentation_ for more details.


pkgId: 04aa23776c9ba26a4120e194e67ec6e94888fb5eb1644a23224da195c4988cc2
name: python-distroinfo
arch: src
version: 0.6.2
epoch: 0
release: 1
url: https://github.com/softwarefactory-project/distroinfo
rpm_license: Apache Software License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-44009308-e716-440a-b9ce-9fb717a91a97
location_href: 00003443-python-distroinfo/python-distroinfo-0.6.2-1.src.rpm
checksum_type: sha256
summary:
  python module for parsing, validating and querying distribution/packaging metadata stored in human readable and reviewable text/YAML files

description:
  ``distroinfo`` is a python module for parsing, validating and querying
  distribution/packaging metadata stored in human readable and reviewable
  text/YAML files.
  This is a proper generic (re)implementation of
  `rdoinfo <https://github.com/redhat-openstack/rdoinfo>`__ parser which
  proved well suited for the task of interfacing with distribution
  metadata in a human friendly way. If you consider code reviews human
  friendly, that is.
  ``distroinfo`` is a part of `Software Factory
  project <https://softwarefactory-project.io/docs/>`__


pkgId: 6e86bc8e0bb22e92c501597f2a296967f4aaabe2b7e42353bf413023c7280498
name: python-dj-database-url
arch: src
version: 1.3.0
epoch: 0
release: 1
summary: Use Database URLs in your Django Application.
url: https://github.com/jazzband/dj-database-url
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-52d6f3e8-eddf-462c-b42f-0fb3b81cb79d
location_href: 00009705-python-dj-database-url/python-dj-database-url-1.3.0-1.src.rpm
checksum_type: sha256
description:
  Support currently exists for PostgreSQL, PostGIS, MySQL, MySQL (GIS),
  Oracle, Oracle (GIS), Redshift, CockroachDB, Timescale, Timescale (GIS) and SQLite.


pkgId: 765fca60f5a0f9f92f1d8addce82fd239d09cf1c0c77836caa9a231b20078cc9
name: python-dj-rest-auth
arch: src
version: 3.0.0
epoch: 0
release: 1
summary: Authentication and Registration in Django Rest Framework
url: http://github.com/iMerica/dj-rest-auth
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-0f9ecda5-eed6-4317-ae65-9eae10fafc0f
location_href: 00011578-python-dj-rest-auth/python-dj-rest-auth-3.0.0-1.src.rpm
checksum_type: sha256
description:
  [![<iMerica>](https://circleci.com/gh/iMerica/dj-rest-auth.svg?style=svg)](https://app.circleci.com/pipelines/github/iMerica/dj-rest-auth)


  Drop-in API endpoints for handling authentication securely in Django Rest Framework. Works especially well
  with SPAs (e.g React, Vue, Angular), and Mobile applications.


  - Django 2, 3 or 4 (See Unit Test Coverage in CI)
  - Python 3



  Install package

      pip install dj-rest-auth

  Add `dj_rest_auth` app to INSTALLED_APPS in your django settings.py:

  ```python
  INSTALLED_APPS = (
      ...,
      'rest_framework',
      'rest_framework.authtoken',
      ...,
      'dj_rest_auth'
  )
  ```

  Add URL patterns

  ```python
  urlpatterns = [
      path('dj-rest-auth/', include('dj_rest_auth.urls')),
  ]
  ```


  (Optional) Use Http-Only cookies

  ```python
  REST_AUTH = {
      'USE_JWT': True,
      'JWT_AUTH_COOKIE': 'jwt-auth',
  }
  ```



  Install required modules with `pip install -r  dj_rest_auth/tests/requirements.pip`

  To run the tests within a virtualenv, run `python runtests.py` from the repository directory.
  The easiest way to run test coverage is with [`coverage`](https://pypi.org/project/coverage/),
  which runs the tests against all supported Django installs. To run the test coverage
  within a virtualenv, run `coverage run ./runtests.py` from the repository directory then run `coverage report`.



  Testing may also be done using [`tox`](https://pypi.org/project/tox/), which
  will run the tests against all supported combinations of python and django.

  Install tox, either globally or within a virtualenv, and then simply run `tox`
  from the repository directory. As there are many combinations, you may run them
  in [`parallel`](https://tox.readthedocs.io/en/latest/config.html#cmdoption-tox-p)
  using `tox --parallel`.

  The `tox.ini` includes an environment for testing code [`coverage`](https://pypi.org/project/coverage/)
  and you can run it and view this report with `tox -e coverage`.

  Linting may also be performed via [`flake8`](https://pypi.org/project/flake8/)
  by running `tox -e flake8`.



  View the full documentation here: https://dj-rest-auth.readthedocs.io/en/latest/index.html




  This project began as a fork of `django-rest-auth`. Big thanks to everyone who contributed to that repo!



  This project has an optional and very narrow support for Django-AllAuth. As maintainer I have no intererest in making this package support every and all use case in Django All Auth. I would rather focus on improving the quality of the base funtionality or focus on OIDC support instead. Pull requests that extend or add more support for Django AllAuth will most likely be declined. Do you disagreee? Feel free to fork this repo!


pkgId: 25703bad066b52a52b368251b1f568d4b20492b7aca2bbdc8052514c5ef9af2f
name: python-dj-static
arch: src
version: 0.0.6
epoch: 0
release: 1
summary: Serve production static files with Django.
url: https://github.com/kennethreitz/dj-static
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e7151c82-7e2e-4338-813e-dfb5de5dedb0
location_href: 00012092-python-dj-static/python-dj-static-0.0.6-1.src.rpm
checksum_type: sha256
description:
  Configure your static assets in ``settings.py``::
     STATIC_ROOT = 'staticfiles'
     STATIC_URL = '/static/'
  Then, update your ``wsgi.py`` file to use dj-static::
      from django.core.wsgi import get_wsgi_application
      from dj_static import Cling
      application = Cling(get_wsgi_application())


pkgId: ff933a081f9e95495d84f38190b12c39488804fd9a1f669e8e25388bbe8f071e
name: python-django-add-default-value
arch: src
version: 0.10.0
epoch: 0
release: 1
url: https://github.com/3YOURMIND/django-add-default-value
rpm_license: Apache-2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5f3f7594-7d62-49bb-ad99-7f0ed1429763
location_href: 00013259-python-django-add-default-value/python-django-add-default-value-0.10.0-1.src.rpm
checksum_type: sha256
summary:
  This django Migration Operation can be used to transfer a fields default value to the database scheme.

description:
  Django Migration Operation that can be used to transfer a field's default value
  to the database scheme.
  [![PyPi](https://img.shields.io/pypi/v/django-add-default-value.svg?branch=master)](https://pypi.python.org/pypi/django-add-default-value/)
  [![License](https://img.shields.io/github/license/3yourmind/django-add-default-value.svg)](./LICENSE)
  [![Contributing](https://img.shields.io/badge/PR-welcome-green.svg)](https://github.com/3YOURMIND/django-add-default-value/pulls)
  [![3yourminD-Careers](https://img.shields.io/badge/3YOURMIND-Hiring-brightgreen.svg)](https://www.3yourmind.com/career)
  [![Stars](https://img.shields.io/github/stars/3YOURMIND/django-add-default-value.svg?style=social&label=Stars)](https://github.com/3YOURMIND/django-add-default-value/stargazers)


pkgId: 258183540beea897610c9910d4ad0f8939cb3eb11f37bb44d3e010440fa75ecc
name: python-django-admin-autocomplete-filter
arch: src
version: 0.7.1
epoch: 0
release: 1
summary: A simple Django app to render list filters in django admin using autocomplete widget
url: https://github.com/farhan0581/django-admin-autocomplete-filter
rpm_license: GNU Lesser General Public License v3 (LGPLv3)
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-76314df3-4676-42de-bdbe-e27dfc998636
checksum_type: sha256
description:
  A simple Django app to render list filters in django admin using an autocomplete widget. This app is heavily inspired by [dal-admin-filters.](https://github.com/shamanu4/dal_admin_filters)

location_href:
  00012736-python-django-admin-autocomplete-filter/python-django-admin-autocomplete-filter-0.7.1-1.src.rpm


pkgId: 01a074bd1699a28147762d1bce2ad734df8056e2d3c0bd0a0c4162c8437a3d08
name: python-django-admin-autocomplete-filter-help
arch: noarch
version: 0.7.1
epoch: 0
release: 1
summary: Development documents and examples for django-admin-autocomplete-filter
url: https://github.com/farhan0581/django-admin-autocomplete-filter
rpm_license: GNU Lesser General Public License v3 (LGPLv3)
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-76314df3-4676-42de-bdbe-e27dfc998636
rpm_sourcerpm: python-django-admin-autocomplete-filter-0.7.1-1.src.rpm
checksum_type: sha256
description:
  A simple Django app to render list filters in django admin using an autocomplete widget. This app is heavily inspired by [dal-admin-filters.](https://github.com/shamanu4/dal_admin_filters)

location_href:
  00012736-python-django-admin-autocomplete-filter/python-django-admin-autocomplete-filter-help-0.7.1-1.noarch.rpm


pkgId: d17ff918a8b04b3dacea80d557fcf17dc8e82b02041328c9a927e82b3be6d116
name: python-django-admin-list-filter-dropdown
arch: src
version: 1.0.3
epoch: 0
release: 1
summary: Use dropdowns in Django admin list filter
description: Use dropdowns in Django admin list filter
url: https://github.com/mrts/django-admin-list-filter-dropdown
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-393f9d97-f1c9-422f-86e1-1a6517df323e
checksum_type: sha256
location_href:
  00012242-python-django-admin-list-filter-dropdown/python-django-admin-list-filter-dropdown-1.0.3-1.src.rpm


pkgId: ba19884d1144536966de3352e32b46657b3b0ba30b366db8dde64e1d9c45d868
name: python-django-admin-list-filter-dropdown-help
arch: noarch
version: 1.0.3
epoch: 0
release: 1
summary: Development documents and examples for django-admin-list-filter-dropdown
description: Use dropdowns in Django admin list filter
url: https://github.com/mrts/django-admin-list-filter-dropdown
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-393f9d97-f1c9-422f-86e1-1a6517df323e
rpm_sourcerpm: python-django-admin-list-filter-dropdown-1.0.3-1.src.rpm
checksum_type: sha256
location_href:
  00012242-python-django-admin-list-filter-dropdown/python-django-admin-list-filter-dropdown-help-1.0.3-1.noarch.rpm


pkgId: 5475dd80676c8a2d065e55e1538a467059a0c4fd914b05f86573440cd48f8b0d
name: python-django-admin-sortable
arch: src
version: 2.3
epoch: 0
release: 1
summary: Drag and drop sorting for models and inline models in Django admin.
url: https://github.com/iambrandontaylor/django-admin-sortable
rpm_license: APL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a93d64fa-79c3-455d-908a-8c1f20b8b607
location_href: 00012531-python-django-admin-sortable/python-django-admin-sortable-2.3-1.src.rpm
checksum_type: sha256
description:
  |PyPI version| |Python versions| |Build Status|
  This project makes it easy to add drag-and-drop ordering to any model in
  Django admin. Inlines for a sortable model may also be made sortable,
  enabling individual items or groups of items to be sortable.
  If you find Django Admin Sortable to be helpful, consider `buying me a
  coffee <https://www.buymeacoffee.com/NY9TUAEwF>`__!
  Sorting model instances with a sortable parent:
     sortable-models
  Sorting inlines:
     sortable-inlines


pkgId: cdc535c31b24ea49380455309780b99bb95a77c412e720d6cf5402566f809fda
name: python-django-admin-sortable2
arch: src
version: 2.1.5
epoch: 0
release: 1
url: https://github.com/jrief/django-admin-sortable2
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-123b07e9-df0a-4a80-bd67-55ad9b25b3d7
location_href: 00011674-python-django-admin-sortable2/python-django-admin-sortable2-2.1.5-1.src.rpm
checksum_type: sha256
summary:
  Generic drag-and-drop sorting for the List, the Stacked- and the Tabular-Inlines Views in the Django Admin

description:
  This Django package adds functionality for generic drag-and-drop ordering of items in the List, the Stacked- and the
  Tabular-Inlines Views of the Django Admin interface.

  [![Build Status](https://github.com/jrief/django-admin-sortable2/actions/workflows/tests.yml/badge.svg)](https://github.com/jrief/django-admin-sortable2/actions/workflows/tests.yml)
  [![PyPI version](https://img.shields.io/pypi/v/django-admin-sortable2.svg)](https://pypi.python.org/pypi/django-admin-sortable2)
  [![Python versions](https://img.shields.io/pypi/pyversions/django-admin-sortable2.svg)](https://pypi.python.org/pypi/django-admin-sortable2)
  [![Django versions](https://img.shields.io/pypi/djversions/django-admin-sortable2)](https://pypi.python.org/pypi/django-admin-sortable2)
  [![Downloads](https://img.shields.io/pypi/dm/django-admin-sortable2.svg)](https://img.shields.io/pypi/dm/django-admin-sortable2.svg)
  [![Software license](https://img.shields.io/pypi/l/django-admin-sortable2.svg)](https://github.com/jrief/django-admin-sortable2/blob/master/LICENSE)

  Check the demo:

  ![Demo](https://raw.githubusercontent.com/jrief/django-admin-sortable2/master/docs/source/_static/django-admin-sortable2.gif)

  This library offers simple mixin classes which enrich the functionality of any existing class inheriting from
  `admin.ModelAdmin`, `admin.StackedInline` or `admin.TabularInline`.

  It thus makes it very easy to integrate with existing models and their model admin interfaces. Existing models can
  inherit from `models.Model` or any other class derived thereof. No special base class is required.




  This is a major rewrite of this **django-admin-sortable2**. It replaces the client side part against
  [Sortable.JS](https://sortablejs.github.io/Sortable/) and thus the need for jQuery.

  Replacing that library allowed me to add a new feature: Multiple items can now be dragged and dropped together.




  https://github.com/jrief/django-admin-sortable2

  Detailled documentation can be found on [ReadTheDocs](https://django-admin-sortable2.readthedocs.org/en/latest/).

  Before reporting bugs or asking questions, please read the
  [contributor's guide](https://django-admin-sortable2.readthedocs.io/en/latest/contributing.html).




  Licensed under the terms of the MIT license.

  Copyright &copy; 2013-2022 Jacob Rief and contributors.

  Please follow me on
  [![Twitter Follow](https://img.shields.io/twitter/follow/jacobrief.svg?style=social&label=Jacob+Rief)](https://twitter.com/jacobrief)
  for updates and other news.


pkgId: fa70d806d94974df0af4b23efa64dc3ade32876b4003fe666abcccbc712462e7
name: python-django-ajax-selects
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: Edit ForeignKey, ManyToManyField and CharField in Django Admin using jQuery UI AutoComplete.
url: https://github.com/crucialfelix/django-ajax-selects/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e1847e77-912e-4666-8e3e-a98a886db16c
location_href: 00003446-python-django-ajax-selects/python-django-ajax-selects-2.2.0-1.src.rpm
checksum_type: sha256
description:
  Edit ForeignKey, ManyToManyField and CharField in Django Admin using jQuery UI AutoComplete.

  - Customize search query
  - Query other resources besides Django ORM
  - Format results with HTML
  - Customize styling
  - Customize security policy
  - Add additional custom UI alongside widget
  - Integrate with other UI elements elsewhere on the page using the javascript API
  - Works in Admin as well as in normal views

  - Django >=3, <=4
  - Python >=3.6


pkgId: 4fe34b65407ee57a8eed18596ed0383346bafbc0a00d74e993cf00a1e6861d41
name: python-django-allauth
arch: src
version: 0.54.0
epoch: 0
release: 1
url: http://www.intenct.nl/projects/django-allauth/
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-03ffcb3e-8240-4f66-89af-e893e5cdcbce
location_href: 00010031-python-django-allauth/python-django-allauth-0.54.0-1.src.rpm
checksum_type: sha256
summary:
  Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication.


pkgId: 0791e3c398eccbdd7140be61ac7dc48c2a5eeda1c03c25971157f58a6c227e20
name: python-django-amazon-ses
arch: src
version: 4.0.1
epoch: 0
release: 1
summary: A Django email backend that uses Boto3 to interact with Amazon Simple Email Service (SES).
url: https://github.com/azavea/django-amazon-ses
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9d6a08c6-a82b-45f1-8b59-beb47de7deea
location_href: 00013363-python-django-amazon-ses/python-django-amazon-ses-4.0.1-1.src.rpm
checksum_type: sha256
description:
  A Django email backend that uses `Boto 3 <https://boto3.readthedocs.io/en/latest/>`_ to interact with `Amazon Simple Email Service (SES) <https://aws.amazon.com/ses/>`_.


pkgId: a4af8513d2982e0a76b1308a4ef4c15fab8f75644d6e1ce16d292245b240e453
name: python-django-angular
arch: src
version: 2.3
epoch: 0
release: 1
summary: Let Django play well with AngularJS
url: https://github.com/jrief/django-angular
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b552f623-9743-4524-8551-37f466c0732b
location_href: 00003447-python-django-angular/python-django-angular-2.3-1.src.rpm
checksum_type: sha256
description:
  Let Django play well with AngularJS

  [![Build Status](https://travis-ci.org/jrief/django-angular.svg?branch=master)](https://travis-ci.org/jrief/django-angular)
  [![PyPI version](https://img.shields.io/pypi/v/django-angular.svg)](https://pypi.python.org/pypi/django-angular)
  [![Python versions](https://img.shields.io/pypi/pyversions/django-angular.svg)](https://pypi.python.org/pypi/django-angular)
  [![Software license](https://img.shields.io/pypi/l/django-angular.svg)](https://github.com/jrief/django-angular/blob/master/LICENSE-MIT)
  [![Twitter Follow](https://img.shields.io/twitter/follow/jacobrief.svg?style=social&label=Jacob+Rief)](https://twitter.com/jacobrief)



  Add AngularJS directives to Django Forms. This allows to handle client side form validation using
  the constraints provided by the server side Form declaration.

  For more information, please visit the [demo site](https://django-angular.awesto.com/form_validation/).




  ```
  git clone https://github.com/jrief/django-angular.git django-angular.git
  cd django-angular.git
  docker build -t django-angular.git .
  docker run -d -it -p 9002:9002 django-angular.git
  ```

  Open the application at `http://{docker-host's-ip}:9002/`



  To be compliant with other libraries such as **djangorestframework**,  server-side responses on
  rejected forms use error code 422, rather than 200. If you use your own form controllers, adopt
  them accordingly. The JSON format used to communicate errors downstream has changed slightly.



  For a smoother transition path, **django-angular** added two directives in version 2.0:

  ``<form djng-endpoint="/path/to/endpoint">...</form>``, which can be used to upload form
  data to the server. It also populates the error fields, in case the server rejected some data.

  ``<djng-forms-set endpoint="/path/to/endpoint"><form ...>...</form>...</djng-forms-set>``
  Similar to the above directive, but rather than validating one single form, it validates a
  set of forms using one shared endpoint.

  A promise chain has been introduced. Buttons used to submit form data and then proceed with
  something else, now can be written as:

  ``<button ng-click="do(update()).then(redirectTo('/path/to/other/page'))">Label</button>``




  Detailed documentation on [ReadTheDocs](http://django-angular.readthedocs.org/en/latest/).

  [Demo](http://django-angular.awesto.com/form_validation/) on how to combine Django with Angular's form validation.

  Please drop me a line, if and where you use this project.




  * Seamless integration of Django forms with AngularJS controllers.
  * Client side form validation for Django forms using AngularJS.
  * Let an AngularJS controller call methods in a Django view - kind of Javascript RPCs.
  * Manage Django URLs for static controller files.
  * Three way data binding to connect AngularJS models with a server side message queue.
  * Perform basic CRUD operations.



  * Implement Filter On Single Page Application using Django & Angular JS https://shriniket.home.blog/2019/09/22/integrate-angular-js-with-django-filter-application/




  Copyright &copy; 2019

  MIT licensed


pkgId: 457e14f3fee875f801600282a16b4d77f1127b0486dc07093a9b360b5fce51ca
name: python-django-annoying
arch: src
version: 0.10.6
epoch: 0
release: 1
summary: This is a django application that tries to eliminate annoying things in the Django framework.
url: https://github.com/skorokithakis/django-annoying
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ac944593-775c-419c-af10-3e041be59f78
location_href: 00003449-python-django-annoying/python-django-annoying-0.10.6-1.src.rpm
checksum_type: sha256
description:
  **Features:**

      - render_to decorator - Reduce typing in django views.
      - signals decorator - Allow using signals as decorators.
      - ajax_request decorator - Returns JsonResponse with dict as content.
      - autostrip decorator - Strip form text fields before validation.
      - get_object_or_None function - Similar to get_object_or_404, but returns None if the object is not found.
      - get_config function - Get settings from django.conf if exists, return a default value otherwise.
      - AutoOneToOne field - Creates related object on first call if it doesn't exist yet.
      - HttpResponseReload - Reload and stay on same page from where request was made.
      - StaticServer middleware - Instead of configuring urls.py, just add this middleware and it will serve you static files.
      - JSONField - A field that stores a Python object as JSON and retrieves it as a Python object.


  **Installation instructions:**

       - Copy the "annoying" directory to your Django project or put it in your PYTHONPATH.
       - You can also run "python setup.py install", "easy_install django-annoying", or "pip install django-annoying".


  **Download:**

      - git clone git://github.com/skorokithakis/django-annoying.git
      - hg clone http://bitbucket.org/Stavros/django-annoying/


pkgId: da53f51e51f859e0c610a33c0fe7e643a65ce7f150aa022edcb1b0674cf48ac3
name: python-django-anymail
arch: src
version: 9.1
epoch: 0
release: 1
url: https://github.com/anymail/django-anymail
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1ceedfd7-0a7e-4688-9bad-f68281b37912
location_href: 00010471-python-django-anymail/python-django-anymail-9.1-1.src.rpm
checksum_type: sha256
summary:
  Django email backends and webhooks for Amazon SES, MailerSend, Mailgun, Mailjet, Mandrill, Postal, Postmark, SendGrid, SendinBlue, and SparkPost

description:
      * Github: project page, exactly as it appears here
      * Docs: shared-intro section gets included in docs/index.rst
              quickstart section gets included in docs/quickstart.rst
      * PyPI: project page (via setup.py long_description),
              with several edits to freeze it to the specific PyPI release
              (see long_description_from_readme in setup.py)
      You can use docutils 1.0 markup, but *not* any Sphinx additions.
      GitHub rst supports code-block, but *no other* block directives.
  Anymail lets you send and receive email in Django using your choice
  of transactional email service providers (ESPs). It extends the
  standard `django.core.mail` with many common ESP-added features, providing
  a consistent API that avoids locking your code to one specific ESP
  (and making it easier to change ESPs later if needed).
  Anymail currently supports these ESPs:
  * **Amazon SES**
  * **MailerSend**
  * **Mailgun**
  * **Mailjet**
  * **Mandrill** (MailChimp transactional)
  * **Postal** (self-hosted ESP)
  * **Postmark**
  * **SendGrid**
  * **SendinBlue**
  * **SparkPost**
  Anymail includes:
  * Integration of each ESP's sending APIs into
    `Django's built-in email <https://docs.djangoproject.com/en/v9.1/topics/email/>`_
    package, including support for HTML, attachments, extra headers,
    and other standard email features
  * Extensions to expose common ESP-added functionality, like tags, metadata,
    and tracking, with code that's portable between ESPs
  * Simplified inline images for HTML email
  * Normalized sent-message status and tracking notification, by connecting
    your ESP's webhooks to Django signals
  * "Batch transactional" sends using your ESP's merge and template features
  * Inbound message support, to receive email through your ESP's webhooks,
    with simplified, portable access to attachments and other inbound content
  Anymail maintains compatibility with all Django versions that are in mainstream
  or extended support, plus (usually) a few older Django versions, and is extensively
  tested on all Python versions supported by Django. (Even-older Django versions
  may still be covered by an Anymail extended support release; consult the
  `changelog <https://anymail.dev/en/v9.1/changelog/>`_ for details.)
  Anymail releases follow `semantic versioning <https://semver.org/>`_.
  The package is released under the BSD license.
  **Resources**
  * Full documentation: https://anymail.dev/en/v9.1/
  * Help and troubleshooting: https://anymail.dev/en/v9.1/help/
  * Package on PyPI: https://pypi.org/project/django-anymail/
  * Project on Github: https://github.com/anymail/django-anymail
  * Changelog: https://anymail.dev/en/v9.1/changelog/


pkgId: 289396d63863653b6b3a2703b58d3e2e11c1da5d4db02d1049997ab72edcb29d
name: python-django-appconf
arch: src
version: 1.0.5
epoch: 0
release: 1
summary: A helper class for handling configuration defaults of packaged apps gracefully.
url: https://django-appconf.readthedocs.io/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a5fb2568-76c6-4dd0-9439-9e95a0829600
location_href: 00003451-python-django-appconf/python-django-appconf-1.0.5-1.src.rpm
checksum_type: sha256
description:
  A helper class for handling configuration defaults of packaged Django
  apps gracefully.
      This app precedes Django's own AppConfig_ classes that act as
      "objects [to] store metadata for an application" inside Django's
      app loading mechanism. In other words, they solve a related but
      different use case than django-appconf and can't easily be used
      as a replacement. The similarity in name is purely coincidental.


pkgId: dc46cb63f3028659a0f0848e12d10fd59403a6498f620c15e7c09656f0ec89e7
name: python-django-autocomplete-light
arch: src
version: 3.9.4
epoch: 0
release: 1
summary: Fresh autocompletes for Django
url: http://django-autocomplete-light.rtfd.org
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1bcd7e00-0c79-49f7-b5a1-06e2612f4d35
location_href: 00011043-python-django-autocomplete-light/python-django-autocomplete-light-3.9.4-1.src.rpm
checksum_type: sha256
description:
  - Python 2.7, 3.4, Django 2.0+ support (Django 1.11 (LTS), is supported until django-autocomplete-light-3.2.10),
  - Django (multiple) choice support,
  - Django (multiple) model choice support,
  - Django generic foreign key support (through django-querysetsequence),
  - Django generic many to many relation support (through django-generic-m2m and
    django-gm2m)
  - Multiple widget support: select2.js, easy to add more.
  - Creating choices that don't exist in the autocomplete,
  - Offering choices that depend on other fields in the form, in an elegant and
    innovative way,
  - Dynamic widget creation (ie. inlines), supports YOUR custom scripts too,
  - Provides a test API for your awesome autocompletes, to support YOUR custom
    use cases too,
  - A documented automatically tested example for each use case in test_project.


pkgId: 0497e3a7312b574da4ac785eb69459217738e1075c7fa812fa00cacdfb708c53
name: python-django-autoslug
arch: src
version: 1.9.9
epoch: 0
release: 1
summary: An automated slug field for Django.
url: https://github.com/justinmayer/django-autoslug/
rpm_license: GNU Lesser General Public License (LGPL), Version 3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c6ed7a77-318f-4122-82df-c0c0e3629ea2
location_href: 00011843-python-django-autoslug/python-django-autoslug-1.9.9-1.src.rpm
checksum_type: sha256
description:
  *Python 3.7+ or PyPy*.
  *Django 3.2* or higher.
  It may be possible to successfully use django-autoslug in other environments
  but they are not tested.
    PyPy3 is not officially supported only because there were some problems with
    permissions and ``__pycache__`` on CI unrelated to django-autoslug itself.


pkgId: f4a65a498886d69e67d4c08e7a212a9055c9542ca1e8f73a6a1c2bd9a002f745
name: python-django-axes
arch: src
version: 5.41.0
epoch: 0
release: 1
summary: Keep track of failed login attempts in Django-powered sites.
url: https://github.com/jazzband/django-axes
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-eb953003-7ad4-41ba-a56d-17700a62d1c5
location_href: 00010792-python-django-axes/python-django-axes-5.41.0-1.src.rpm
checksum_type: sha256
description:
  Axes is a Django plugin for keeping track of suspicious
  login attempts for your Django based website
  and implementing simple brute-force attack blocking.
  The name is sort of a geeky pun, since it can be interpreted as:
  * ``access``, as in monitoring access attempts, or
  * ``axes``, as in tools you can use to hack (generally on wood).


pkgId: ac6af64889a104fb36b0b5b49f145c72e4c36771ff47f7bb3980a4cebe9a97df
name: python-django-better-admin-arrayfield
arch: src
version: 1.4.2
epoch: 0
release: 1
summary: Better ArrayField widget for admin
url: https://github.com/gradam/django-better-admin-arrayfield
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ae421fdf-d207-4fbf-8341-99de3daba76a
checksum_type: sha256
description:
  [![image](https://badge.fury.io/py/django-better-admin-arrayfield.svg)](https://badge.fury.io/py/django-better-admin-arrayfield)

  [![Actions Status](https://github.com/gradam/django-better-admin-arrayfield/workflows/tests/badge.svg)](https://github.com/gradam/django-better-admin-arrayfield/actions)

  [![image](https://codecov.io/gh/gradam/django-better-admin-arrayfield/branch/master/graph/badge.svg)](https://codecov.io/gh/gradam/django-better-admin-arrayfield)

  Better ArrayField widget for admin

  Supported Python versions: [![Python 3.5](https://img.shields.io/badge/python-3.5-blue.svg)](https://www.python.org/downloads/release/python-350/) [![Python 3.6](https://img.shields.io/badge/python-3.6-blue.svg)](https://www.python.org/downloads/release/python-360/) [![Python 3.7](https://img.shields.io/badge/python-3.7-blue.svg)](https://www.python.org/downloads/release/python-370/) [![Python 3.8](https://img.shields.io/badge/python-3.8-blue.svg)](https://www.python.org/downloads/release/python-380/)





  Supported Django versions: 2.0, 2.1, 2.2, 3.0, 3.1

  might work with different django/python versions as well but I did not test that.

  It changes comma separated widget to list based in admin panel.

  Before:
  ![Alt text](https://raw.githubusercontent.com/gradam/django-better-admin-arrayfield/master/readme_images/before.jpg "Before")

  After:
  ![Alt text](https://raw.githubusercontent.com/gradam/django-better-admin-arrayfield/master/readme_images/after.png "After")



  Install Django better admin ArrayField:

      pip install django-better-admin-arrayfield

  Add it to your \`INSTALLED\_APPS\`:

  ```python
  INSTALLED_APPS = (
      ...
      'django_better_admin_arrayfield',
      ...
  )
  ```




  `django_better_admin_arrayfield.models.fields.ArrayField` is a drop-in replacement for standard Django `ArrayField`.

  Import it like below and use it in your model class definition.
  ```python
  from django_better_admin_arrayfield.models.fields import ArrayField
  ```

  Import DynamicArrayMixin like below
  ```python
  from django_better_admin_arrayfield.admin.mixins import DynamicArrayMixin
  ```

  In your admin class add `DynamicArrayMixin`:
      ...
  ```python
  class MyModelAdmin(admin.ModelAdmin, DynamicArrayMixin):
  ```

  That's it.




  By default the subwidget (the one used for each item in the array) will be TextInput. If you want something else, you can use your own specifying it in the `formfield_overrides` of your Admin model:
  ```python
  class MyWidget(DynamicArrayWidget):
      def __init__(self, *args, **kwargs):
          kwargs['subwidget_form'] = MyForm
          super().__init__(*args, **kwargs)

  class MyModelAdmin(models.ModelAdmin, DynamicArrayMixin):
      ...
      formfield_overrides = {
          DynamicArrayField: {'widget': MyWidget},
      }
  ```

  If you wanted to have Textarea as the subwidget, you can simply use the included drop-in widget replacement:
  ```python
  from django_better_admin_arrayfield.forms.widgets import DynamicArrayTextareaWidget

  class MyModelAdmin(models.ModelAdmin, DynamicArrayMixin):
      ...
      formfield_overrides = {
          DynamicArrayField: {'widget': DynamicArrayTextareaWidget},
      }
  ```



  Does the code actually work?

      source <YOURVIRTUALENV>/bin/activate
      (myenv) $ pip install tox
      (myenv) $ tox



  Install pre-commit black hook

      source <YOURVIRTUALENV>/bin/activate
      (myenv) $ pip install -r requirements_dev.txt
      (myenv) $ pre-commit install



  Inspired by: https://stackoverflow.com/a/49370480/4638248

  Tools used in rendering this
      package:

    - [Cookiecutter](https://github.com/audreyr/cookiecutter)
    - [cookiecutter-djangopackage](https://github.com/pydanny/cookiecutter-djangopackage)






    - Adjust template to better match django style



    - Allow submitting empty array field



    - allow choosing subwidget for DynamicArrayWidget



    - Handle default values in form field



    - Fix tests requirements



    - handle default values in model fields



    - Add spanish translations



    - Add possibility to i18n strings



    - Remove debugging print statements
    - use default_app_config for easier integration
    - Support dynamically-added inline forms



    - Add python 3.8 and Django 3.0 to tests



    - Can add item after removing everything from the list



    - Can add item after removing everything from the list
    - Do not call static at startup time



    - If field is required empty list raises ValidationError on clean.



    - Empty list is no longer recognized as changed.




    - First release on PyPI.

location_href:
  00012436-python-django-better-admin-arrayfield/python-django-better-admin-arrayfield-1.4.2-1.src.rpm


pkgId: 0c3cb856b199bc892de42f5434d058f62d6ac420a06ec350054c9545614e62ba
name: python-django-better-admin-arrayfield-help
arch: noarch
version: 1.4.2
epoch: 0
release: 1
summary: Development documents and examples for django-better-admin-arrayfield
url: https://github.com/gradam/django-better-admin-arrayfield
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ae421fdf-d207-4fbf-8341-99de3daba76a
rpm_sourcerpm: python-django-better-admin-arrayfield-1.4.2-1.src.rpm
checksum_type: sha256
description:
  [![image](https://badge.fury.io/py/django-better-admin-arrayfield.svg)](https://badge.fury.io/py/django-better-admin-arrayfield)

  [![Actions Status](https://github.com/gradam/django-better-admin-arrayfield/workflows/tests/badge.svg)](https://github.com/gradam/django-better-admin-arrayfield/actions)

  [![image](https://codecov.io/gh/gradam/django-better-admin-arrayfield/branch/master/graph/badge.svg)](https://codecov.io/gh/gradam/django-better-admin-arrayfield)

  Better ArrayField widget for admin

  Supported Python versions: [![Python 3.5](https://img.shields.io/badge/python-3.5-blue.svg)](https://www.python.org/downloads/release/python-350/) [![Python 3.6](https://img.shields.io/badge/python-3.6-blue.svg)](https://www.python.org/downloads/release/python-360/) [![Python 3.7](https://img.shields.io/badge/python-3.7-blue.svg)](https://www.python.org/downloads/release/python-370/) [![Python 3.8](https://img.shields.io/badge/python-3.8-blue.svg)](https://www.python.org/downloads/release/python-380/)





  Supported Django versions: 2.0, 2.1, 2.2, 3.0, 3.1

  might work with different django/python versions as well but I did not test that.

  It changes comma separated widget to list based in admin panel.

  Before:
  ![Alt text](https://raw.githubusercontent.com/gradam/django-better-admin-arrayfield/master/readme_images/before.jpg "Before")

  After:
  ![Alt text](https://raw.githubusercontent.com/gradam/django-better-admin-arrayfield/master/readme_images/after.png "After")



  Install Django better admin ArrayField:

      pip install django-better-admin-arrayfield

  Add it to your \`INSTALLED\_APPS\`:

  ```python
  INSTALLED_APPS = (
      ...
      'django_better_admin_arrayfield',
      ...
  )
  ```




  `django_better_admin_arrayfield.models.fields.ArrayField` is a drop-in replacement for standard Django `ArrayField`.

  Import it like below and use it in your model class definition.
  ```python
  from django_better_admin_arrayfield.models.fields import ArrayField
  ```

  Import DynamicArrayMixin like below
  ```python
  from django_better_admin_arrayfield.admin.mixins import DynamicArrayMixin
  ```

  In your admin class add `DynamicArrayMixin`:
      ...
  ```python
  class MyModelAdmin(admin.ModelAdmin, DynamicArrayMixin):
  ```

  That's it.




  By default the subwidget (the one used for each item in the array) will be TextInput. If you want something else, you can use your own specifying it in the `formfield_overrides` of your Admin model:
  ```python
  class MyWidget(DynamicArrayWidget):
      def __init__(self, *args, **kwargs):
          kwargs['subwidget_form'] = MyForm
          super().__init__(*args, **kwargs)

  class MyModelAdmin(models.ModelAdmin, DynamicArrayMixin):
      ...
      formfield_overrides = {
          DynamicArrayField: {'widget': MyWidget},
      }
  ```

  If you wanted to have Textarea as the subwidget, you can simply use the included drop-in widget replacement:
  ```python
  from django_better_admin_arrayfield.forms.widgets import DynamicArrayTextareaWidget

  class MyModelAdmin(models.ModelAdmin, DynamicArrayMixin):
      ...
      formfield_overrides = {
          DynamicArrayField: {'widget': DynamicArrayTextareaWidget},
      }
  ```



  Does the code actually work?

      source <YOURVIRTUALENV>/bin/activate
      (myenv) $ pip install tox
      (myenv) $ tox



  Install pre-commit black hook

      source <YOURVIRTUALENV>/bin/activate
      (myenv) $ pip install -r requirements_dev.txt
      (myenv) $ pre-commit install



  Inspired by: https://stackoverflow.com/a/49370480/4638248

  Tools used in rendering this
      package:

    - [Cookiecutter](https://github.com/audreyr/cookiecutter)
    - [cookiecutter-djangopackage](https://github.com/pydanny/cookiecutter-djangopackage)






    - Adjust template to better match django style



    - Allow submitting empty array field



    - allow choosing subwidget for DynamicArrayWidget



    - Handle default values in form field



    - Fix tests requirements



    - handle default values in model fields



    - Add spanish translations



    - Add possibility to i18n strings



    - Remove debugging print statements
    - use default_app_config for easier integration
    - Support dynamically-added inline forms



    - Add python 3.8 and Django 3.0 to tests



    - Can add item after removing everything from the list



    - Can add item after removing everything from the list
    - Do not call static at startup time



    - If field is required empty list raises ValidationError on clean.



    - Empty list is no longer recognized as changed.




    - First release on PyPI.

location_href:
  00012436-python-django-better-admin-arrayfield/python-django-better-admin-arrayfield-help-1.4.2-1.noarch.rpm


pkgId: 743a6ff850a5901a6d3c1066e8490c02b95755b4b395deb59e3ccc17481b3ba8
name: python-django-bootstrap3
arch: src
version: 23.1
epoch: 0
release: 1
summary: Bootstrap 3 support for Django projects
url: https://github.com/zostera/django-bootstrap3
rpm_license: BSD-3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ef2525cb-2a17-4ca7-8d4a-4a88d08d312a
location_href: 00011669-python-django-bootstrap3/python-django-bootstrap3-23.1-1.src.rpm
checksum_type: sha256
description:
  A demo app is provided in `demo`. You can run it from your virtualenv with `python manage.py runserver`.


pkgId: cb2e88b5221ae3f3204ea6631391dd88594ccfc8def259b6e76fb5ba9623daab
name: python-django-bootstrap4
arch: src
version: 23.1
epoch: 0
release: 1
summary: Bootstrap 4 for Django
url: https://github.com/zostera/django-bootstrap4
rpm_license: BSD-3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d4ae2619-1169-4326-b33c-7ebaf5455346
location_href: 00011246-python-django-bootstrap4/python-django-bootstrap4-23.1-1.src.rpm
checksum_type: sha256
description:
  [![CI](https://github.com/zostera/django-bootstrap4/workflows/CI/badge.svg?branch=main)](https://github.com/zostera/django-bootstrap4/actions?workflow=CI)
  [![Coverage Status](https://coveralls.io/repos/github/zostera/django-bootstrap4/badge.svg?branch=main)](https://coveralls.io/github/zostera/django-bootstrap4?branch=main)
  [![Latest PyPI version](https://img.shields.io/pypi/v/django-bootstrap4.svg)](https://pypi.python.org/pypi/django-bootstrap4)
  [![Any color you like](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/ambv/black)

  Bootstrap 4 integration for Django.



  The goal of this project is to seamlessly blend Django and Bootstrap 4.



  Python 3.7 or newer with Django 3.2 or newer.



  The full documentation is at https://django-bootstrap4.readthedocs.io/



  1. Install using pip:

  ```bash
  pip install django-bootstrap4
  ```

     Alternatively, you can install download or clone this repo and call ``pip install -e .``.

  2. Add to `INSTALLED_APPS` in your `settings.py`:

  ```python
  INSTALLED_APPS = (
    
    "bootstrap4",
    
  )
  ```

  3. In your templates, load the `bootstrap4` library and use the `bootstrap_*` tags. See example below.



  ```jinja
  {% load bootstrap4 %}

  {# Display a form #}

  <form action="/url/to/submit/" method="post" class="form">
      {% csrf_token %}
      {% bootstrap_form form %}
      {% buttons %}
          <button type="submit" class="btn btn-primary">Submit</button>
      {% endbuttons %}
  </form>
  ```



  A demo app is provided in `demo`. You can run it from your virtualenv with `python manage.py runserver`.



  If you have found a bug or if you have a request for additional functionality, please use the issue tracker on GitHub.

  https://github.com/zostera/django-bootstrap4/issues



  You can use this under BSD-3-Clause. See [LICENSE](LICENSE) file for details.



  Developed and maintained by [Zostera](https://zostera.nl).

  Original author: [Dylan Verheul](https://github.com/dyve).

  Thanks to everybody that has contributed pull requests, ideas, issues, comments and kind words.

  Please see [AUTHORS](AUTHORS) for a list of contributors.


pkgId: 1b042a1cfb1991b2b6857cfe9613f6490ecbbd72f5534bbe124ea1732753238b
name: python-django-bulk-update
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: Bulk update using one query over Django ORM.
url: https://github.com/aykut/django-bulk-update
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4c296c0c-4ea1-40d8-906f-6f80065bc5b5
location_href: 00011083-python-django-bulk-update/python-django-bulk-update-2.2.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/aykut/django-bulk-update.svg?branch=master)](https://travis-ci.org/aykut/django-bulk-update)
  [![Coverage Status](https://coveralls.io/repos/aykut/django-bulk-update/badge.svg?branch=master)](https://coveralls.io/r/aykut/django-bulk-update?branch=master)
  Simple bulk update over Django ORM or with helper function.
  This project aims to bulk update given objects using **one query** over
  **Django ORM**.


pkgId: 44ddf781f84c55c60bacd7759bac6d2e884b05836f3bc143950c1122eee23522
name: python-django-cache-url
arch: src
version: 3.4.4
epoch: 0
release: 1
summary: Use Cache URLs in your Django application.
url: https://github.com/epicserve/django-cache-url
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d4056243-cc1f-4ea0-bcd1-de30e4b48065
location_href: 00012893-python-django-cache-url/python-django-cache-url-3.4.4-1.src.rpm
checksum_type: sha256
description:
  Configure your cache in ``settings.py``::
      CACHES={'default': django_cache_url.config()}
  Nice and simple.


pkgId: 369782843d6b55b1f1b121fecb78adbf052423b869e2ab93b5ecb4679772012d
name: python-django-cacheops
arch: src
version: 6.2
epoch: 0
release: 1
summary: A slick ORM cache with automatic granular event-driven invalidation for Django.
url: http://github.com/Suor/django-cacheops
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a8d6ca12-90da-4bd2-9aa6-2457567d3018
location_href: 00003453-python-django-cacheops/python-django-cacheops-6.2-1.src.rpm
checksum_type: sha256
description:
  A slick app that supports automatic or manual queryset caching and `automatic
  granular event-driven invalidation <http://suor.github.io/blog/2014/03/09/on-orm-cache-invalidation/>`_.
  It uses `redis <http://redis.io/>`_ as backend for ORM cache and redis or
  filesystem for simple time-invalidated one.
  And there is more to it:
  - decorators to cache any user function or view as a queryset or by time
  - extensions for django and jinja2 templates
  - transparent transaction support
  - dog-pile prevention mechanism
  - a couple of hacks to make django faster
  Requirements
  ++++++++++++
  Python 3.5+, Django 2.1+ and Redis 4.0+.
  Installation
  ++++++++++++
  Using pip:
      $ pip install django-cacheops
      
      $ pip install git+https://github.com/Suor/django-cacheops.git@master
  Setup
  +++++
  Add ``cacheops`` to your ``INSTALLED_APPS``.
  Setup redis connection and enable caching for desired models:
      CACHEOPS_REDIS = {
          'host': 'localhost', # redis-server is on same machine
          'port': 6379,        # default redis port
          'db': 1,             # SELECT non-default redis database
                               
                               
          'socket_timeout': 3,   # connection timeout in seconds, optional
          'password': '...',     # optional
          'unix_socket_path': '' # replaces host and port
      }
      
      CACHEOPS_REDIS = "redis://localhost:6379/1"
      
      CACHEOPS_REDIS = "unix://path/to/socket?db=1"
      
      CACHEOPS_REDIS = "redis://:password@localhost:6379/1"
      
      CACHEOPS_SENTINEL = {
          'locations': [('localhost', 26379)], # sentinel locations, required
          'service_name': 'mymaster',          # sentinel service name, required
          'socket_timeout': 0.1,               # connection timeout in seconds, optional
          'db': 0                              # redis database, default: 0
      }
      
      
      CACHEOPS_CLIENT_CLASS = 'your.redis.ClientClass'
      CACHEOPS = {
          
          
          
          
          'auth.user': {'ops': 'get', 'timeout': 60*15},
          
          
          'auth.*': {'ops': {'fetch', 'get'}, 'timeout': 60*60},
          
          
          'auth.permission': {'ops': 'all', 'timeout': 60*60},
          
          
          
          
          
          '*.*': {'ops': (), 'timeout': 60*60},
          
          '*.*': {'timeout': 60*60},
          
          
          
          'some_app.*': None,
      }
  You can configure default profile setting with ``CACHEOPS_DEFAULTS``. This way you can rewrite the config above:
      CACHEOPS_DEFAULTS = {
          'timeout': 60*60
      }
      CACHEOPS = {
          'auth.user': {'ops': 'get', 'timeout': 60*15},
          'auth.*': {'ops': ('fetch', 'get')},
          'auth.permission': {'ops': 'all'},
          '*.*': {},
      }
  Using ``'*.*'`` with non-empty ``ops`` is **not recommended**
  since it will easily cache something you don't intent to or even know about like migrations tables.
  The better approach will be restricting by app with ``'app_name.*'``.
  Besides ``ops`` and ``timeout`` options you can also use:
  ``local_get: True``
      To cache simple gets for this model in process local memory.
      This is very fast, but is not invalidated in any way until process is restarted.
      Still could be useful for extremely rarely changed things.
  ``cache_on_save=True | 'field_name'``
      To write an instance to cache upon save.
      Cached instance will be retrieved on ``.get(field_name=...)`` request.
      Setting to ``True`` causes caching by primary key.
  Additionally, you can tell cacheops to degrade gracefully on redis fail with:
      CACHEOPS_DEGRADE_ON_FAILURE = True
  There is also a possibility to make all cacheops methods and decorators no-op, e.g. for testing:
      from django.test import override_settings
      @override_settings(CACHEOPS_ENABLED=False)
      def test_something():
          
          assert cond
  Usage
  +++++
  | **Automatic caching**
  It's automatic you just need to set it up.
  | **Manual caching**
  You can force any queryset to use cache by calling its ``.cache()`` method:
      Article.objects.filter(tag=2).cache()
  Here you can specify which ops should be cached for the queryset, for example, this code:
      qs = Article.objects.filter(tag=2).cache(ops=['count'])
      paginator = Paginator(objects, ipp)
      articles = list(pager.page(page_num)) # hits database
  will cache count call in ``Paginator`` but not later articles fetch.
  There are five possible actions - ``get``, ``fetch``, ``count``, ``aggregate`` and ``exists``.
  You can pass any subset of this ops to ``.cache()`` method even empty - to turn off caching.
  There is, however, a shortcut for the latter:
      qs = Article.objects.filter(visible=True).nocache()
      qs1 = qs.filter(tag=2)       # hits database
      qs2 = qs.filter(category=3)  # hits it once more
  It is useful when you want to disable automatic caching on particular queryset.
  You can also override default timeout for particular queryset with ``.cache(timeout=...)``.
  | **Function caching**
  You can cache and invalidate result of a function the same way as a queryset.
  Cached results of the next function will be invalidated on any ``Article`` change,
  addition or deletion:
      from cacheops import cached_as
      @cached_as(Article, timeout=120)
      def article_stats():
          return {
              'tags': list(Article.objects.values('tag').annotate(Count('id')))
              'categories': list(Article.objects.values('category').annotate(Count('id')))
          }
  Note that we are using list on both querysets here, it's because we don't want
  to cache queryset objects but their results.
  Also note that if you want to filter queryset based on arguments,
  e.g. to make invalidation more granular, you can use a local function:
      def articles_block(category, count=5):
          qs = Article.objects.filter(category=category)
          @cached_as(qs, extra=count)
          def _articles_block():
              articles = list(qs.filter(photo=True)[:count])
              if len(articles) < count:
                  articles += list(qs.filter(photo=False)[:count-len(articles)])
              return articles
          return _articles_block()
  We added ``extra`` here to make different keys for calls with same ``category`` but different
  ``count``. Cache key will also depend on function arguments, so we could just pass ``count`` as
  an argument to inner function. We also omitted ``timeout`` here, so a default for the model
  will be used.
  Another possibility is to make function cache invalidate on changes to any one of several models:
      @cached_as(Article.objects.filter(public=True), Tag)
      def article_stats():
          return {...}
  As you can see, we can mix querysets and models here.
  | **View caching**
  You can also cache and invalidate a view as a queryset. This works mostly the same way as function
  caching, but only path of the request parameter is used to construct cache key:
      from cacheops import cached_view_as
      @cached_view_as(News)
      def news_index(request):
          
          return render(...)
  You can pass ``timeout``, ``extra`` and several samples the same way as to ``@cached_as()``. Note that you can pass a function as ``extra``:
      @cached_view_as(News, extra=lambda req: req.user.is_staff)
      def news_index(request):
          
          return render(...)
  A function passed as ``extra`` receives the same arguments as the cached function.
  Class based views can also be cached:
      class NewsIndex(ListView):
          model = News
      news_index = cached_view_as(News, ...)(NewsIndex.as_view())
  Invalidation
  ++++++++++++
  Cacheops uses both time and event-driven invalidation. The event-driven one
  listens on model signals and invalidates appropriate caches on ``Model.save()``, ``.delete()``
  and m2m changes.
  Invalidation tries to be granular which means it won't invalidate a queryset
  that cannot be influenced by added/updated/deleted object judging by query
  conditions. Most of the time this will do what you want, if it won't you can use
  one of the following:
      from cacheops import invalidate_obj, invalidate_model, invalidate_all
      invalidate_obj(some_article)  # invalidates queries affected by some_article
      invalidate_model(Article)     # invalidates all queries for model
      invalidate_all()              # flush redis cache database
  And last there is ``invalidate`` command::
      ./manage.py invalidate articles.Article.34  # same as invalidate_obj
      ./manage.py invalidate articles.Article     # same as invalidate_model
      ./manage.py invalidate articles   # invalidate all models in articles
  And the one that FLUSHES cacheops redis database::
      ./manage.py invalidate all
  Don't use that if you share redis database for both cache and something else.
  | **Turning off and postponing invalidation**
  There is also a way to turn off invalidation for a while:
      from cacheops import no_invalidation
      with no_invalidation:
          
          obj.save()
  Also works as decorator:
      @no_invalidation
      def some_work(...):
          
          obj.save()
  Combined with ``try ... finally`` it could be used to postpone invalidation:
      try:
          with no_invalidation:
              
      finally:
          invalidate_obj(...)
          
          invalidate_model(...)
  Postponing invalidation can speed up batch jobs.
  | **Mass updates**
  Normally `qs.update(...)` doesn't emit any events and thus doesn't trigger invalidation.
  And there is no transparent and efficient way to do that: trying to act on conditions will
  invalidate too much if update conditions are orthogonal to many queries conditions,
  and to act on specific objects we will need to fetch all of them,
  which `QuerySet.update()` users generally try to avoid.
  In the case you actually want to perform the latter cacheops provides a shortcut:
      qs.invalidated_update(...)
  Note that all the updated objects are fetched twice, prior and post the update.
  Components
  ++++++++++


pkgId: 4a2ef7ae6f35a6a2a9542019f9cbc613363c05b8bbffcc2bb9bd131fc130b70a
name: python-django-cacheops
arch: src
version: 7.0
epoch: 0
release: 1
summary: A slick ORM cache with automatic granular event-driven invalidation for Django.
url: http://github.com/Suor/django-cacheops
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-dc5f829a-8b98-4d13-ac57-1cd8d9008dee
location_href: 00006812-python-django-cacheops/python-django-cacheops-7.0-1.src.rpm
checksum_type: sha256
description:
  A slick app that supports automatic or manual queryset caching and `automatic
  granular event-driven invalidation <http://suor.github.io/blog/2014/03/09/on-orm-cache-invalidation/>`_.
  It uses `redis <http://redis.io/>`_ as backend for ORM cache and redis or
  filesystem for simple time-invalidated one.
  And there is more to it:
  - decorators to cache any user function or view as a queryset or by time
  - extensions for django and jinja2 templates
  - transparent transaction support
  - dog-pile prevention mechanism
  - a couple of hacks to make django faster
  Requirements
  ++++++++++++
  Python 3.7+, Django 3.2+ and Redis 4.0+.
  Installation
  ++++++++++++
  Using pip:
      $ pip install django-cacheops
      
      $ pip install git+https://github.com/Suor/django-cacheops.git@master
  Setup
  +++++
  Add ``cacheops`` to your ``INSTALLED_APPS``.
  Setup redis connection and enable caching for desired models:
      CACHEOPS_REDIS = {
          'host': 'localhost', # redis-server is on same machine
          'port': 6379,        # default redis port
          'db': 1,             # SELECT non-default redis database
                               
                               
          'socket_timeout': 3,   # connection timeout in seconds, optional
          'password': '...',     # optional
          'unix_socket_path': '' # replaces host and port
      }
      
      CACHEOPS_REDIS = "redis://localhost:6379/1"
      
      CACHEOPS_REDIS = "unix://path/to/socket?db=1"
      
      CACHEOPS_REDIS = "redis://:password@localhost:6379/1"
      
      CACHEOPS_SENTINEL = {
          'locations': [('localhost', 26379)], # sentinel locations, required
          'service_name': 'mymaster',          # sentinel service name, required
          'socket_timeout': 0.1,               # connection timeout in seconds, optional
          'db': 0                              # redis database, default: 0
      }
      
      CACHEOPS_CLIENT_CLASS = 'your.redis.ClientClass'
      CACHEOPS = {
          
          
          
          
          'auth.user': {'ops': 'get', 'timeout': 60*15},
          
          
          'auth.*': {'ops': {'fetch', 'get'}, 'timeout': 60*60},
          
          
          'auth.permission': {'ops': 'all', 'timeout': 60*60},
          
          
          
          
          
          '*.*': {'ops': (), 'timeout': 60*60},
          
          '*.*': {'timeout': 60*60},
          
          
          
          'some_app.*': None,
      }
  You can configure default profile setting with ``CACHEOPS_DEFAULTS``. This way you can rewrite the config above:
      CACHEOPS_DEFAULTS = {
          'timeout': 60*60
      }
      CACHEOPS = {
          'auth.user': {'ops': 'get', 'timeout': 60*15},
          'auth.*': {'ops': ('fetch', 'get')},
          'auth.permission': {'ops': 'all'},
          '*.*': {},
      }
  Using ``'*.*'`` with non-empty ``ops`` is **not recommended**
  since it will easily cache something you don't intent to or even know about like migrations tables.
  The better approach will be restricting by app with ``'app_name.*'``.
  Besides ``ops`` and ``timeout`` options you can also use:
  ``local_get: True``
      To cache simple gets for this model in process local memory.
      This is very fast, but is not invalidated in any way until process is restarted.
      Still could be useful for extremely rarely changed things.
  ``cache_on_save=True | 'field_name'``
      To write an instance to cache upon save.
      Cached instance will be retrieved on ``.get(field_name=...)`` request.
      Setting to ``True`` causes caching by primary key.
  Additionally, you can tell cacheops to degrade gracefully on redis fail with:
      CACHEOPS_DEGRADE_ON_FAILURE = True
  There is also a possibility to make all cacheops methods and decorators no-op, e.g. for testing:
      from django.test import override_settings
      @override_settings(CACHEOPS_ENABLED=False)
      def test_something():
          
          assert cond
  Usage
  +++++
  | **Automatic caching**
  It's automatic you just need to set it up.
  | **Manual caching**
  You can force any queryset to use cache by calling its ``.cache()`` method:
      Article.objects.filter(tag=2).cache()
  Here you can specify which ops should be cached for the queryset, for example, this code:
      qs = Article.objects.filter(tag=2).cache(ops=['count'])
      paginator = Paginator(objects, ipp)
      articles = list(pager.page(page_num)) # hits database
  will cache count call in ``Paginator`` but not later articles fetch.
  There are five possible actions - ``get``, ``fetch``, ``count``, ``aggregate`` and ``exists``.
  You can pass any subset of this ops to ``.cache()`` method even empty - to turn off caching.
  There is, however, a shortcut for the latter:
      qs = Article.objects.filter(visible=True).nocache()
      qs1 = qs.filter(tag=2)       # hits database
      qs2 = qs.filter(category=3)  # hits it once more
  It is useful when you want to disable automatic caching on particular queryset.
  You can also override default timeout for particular queryset with ``.cache(timeout=...)``.
  | **Function caching**
  You can cache and invalidate result of a function the same way as a queryset.
  Cached results of the next function will be invalidated on any ``Article`` change,
  addition or deletion:
      from cacheops import cached_as
      @cached_as(Article, timeout=120)
      def article_stats():
          return {
              'tags': list(Article.objects.values('tag').annotate(Count('id')))
              'categories': list(Article.objects.values('category').annotate(Count('id')))
          }
  Note that we are using list on both querysets here, it's because we don't want
  to cache queryset objects but their results.
  Also note that if you want to filter queryset based on arguments,
  e.g. to make invalidation more granular, you can use a local function:
      def articles_block(category, count=5):
          qs = Article.objects.filter(category=category)
          @cached_as(qs, extra=count)
          def _articles_block():
              articles = list(qs.filter(photo=True)[:count])
              if len(articles) < count:
                  articles += list(qs.filter(photo=False)[:count-len(articles)])
              return articles
          return _articles_block()
  We added ``extra`` here to make different keys for calls with same ``category`` but different
  ``count``. Cache key will also depend on function arguments, so we could just pass ``count`` as
  an argument to inner function. We also omitted ``timeout`` here, so a default for the model
  will be used.
  Another possibility is to make function cache invalidate on changes to any one of several models:
      @cached_as(Article.objects.filter(public=True), Tag)
      def article_stats():
          return {...}
  As you can see, we can mix querysets and models here.
  | **View caching**
  You can also cache and invalidate a view as a queryset. This works mostly the same way as function
  caching, but only path of the request parameter is used to construct cache key:
      from cacheops import cached_view_as
      @cached_view_as(News)
      def news_index(request):
          
          return render(...)
  You can pass ``timeout``, ``extra`` and several samples the same way as to ``@cached_as()``. Note that you can pass a function as ``extra``:
      @cached_view_as(News, extra=lambda req: req.user.is_staff)
      def news_index(request):
          
          return render(...)
  A function passed as ``extra`` receives the same arguments as the cached function.
  Class based views can also be cached:
      class NewsIndex(ListView):
          model = News
      news_index = cached_view_as(News, ...)(NewsIndex.as_view())
  Invalidation
  ++++++++++++
  Cacheops uses both time and event-driven invalidation. The event-driven one
  listens on model signals and invalidates appropriate caches on ``Model.save()``, ``.delete()``
  and m2m changes.
  Invalidation tries to be granular which means it won't invalidate a queryset
  that cannot be influenced by added/updated/deleted object judging by query
  conditions. Most of the time this will do what you want, if it won't you can use
  one of the following:
      from cacheops import invalidate_obj, invalidate_model, invalidate_all
      invalidate_obj(some_article)  # invalidates queries affected by some_article
      invalidate_model(Article)     # invalidates all queries for model
      invalidate_all()              # flush redis cache database
  And last there is ``invalidate`` command::
      ./manage.py invalidate articles.Article.34  # same as invalidate_obj
      ./manage.py invalidate articles.Article     # same as invalidate_model
      ./manage.py invalidate articles   # invalidate all models in articles
  And the one that FLUSHES cacheops redis database::
      ./manage.py invalidate all
  Don't use that if you share redis database for both cache and something else.
  | **Turning off and postponing invalidation**
  There is also a way to turn off invalidation for a while:
      from cacheops import no_invalidation
      with no_invalidation:
          
          obj.save()
  Also works as decorator:
      @no_invalidation
      def some_work(...):
          
          obj.save()
  Combined with ``try ... finally`` it could be used to postpone invalidation:
      try:
          with no_invalidation:
              
      finally:
          invalidate_obj(...)
          
          invalidate_model(...)
  Postponing invalidation can speed up batch jobs.
  | **Mass updates**
  Normally `qs.update(...)` doesn't emit any events and thus doesn't trigger invalidation.
  And there is no transparent and efficient way to do that: trying to act on conditions will
  invalidate too much if update conditions are orthogonal to many queries conditions,
  and to act on specific objects we will need to fetch all of them,
  which `QuerySet.update()` users generally try to avoid.
  In the case you actually want to perform the latter cacheops provides a shortcut:
      qs.invalidated_update(...)
  Note that all the updated objects are fetched twice, prior and post the update.
  Components
  ++++++++++


pkgId: 96ea23d677a605ebb7b15a2a1c1c449a06a0b7ff586e8fe4ab322e01ddf9b02a
name: python-django-ckeditor
arch: src
version: 6.5.1
epoch: 0
release: 1
summary: Django admin CKEditor integration.
url: https://github.com/django-ckeditor/django-ckeditor
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bc904ad0-7575-4b0d-b015-68c980d4afcd
location_href: 00010727-python-django-ckeditor/python-django-ckeditor-6.5.1-1.src.rpm
checksum_type: sha256
description:
  **Django admin CKEditor integration.**
  Provides a ``RichTextField``, ``RichTextUploadingField``, ``CKEditorWidget`` and ``CKEditorUploadingWidget`` utilizing CKEditor with image uploading and browsing support included.
  This version also includes:


pkgId: c4e94a5dc50f3cf4dace86f90c27552ae7ea43e725ca7d5af9b03793c5f435f0
name: python-django-cleanup
arch: src
version: 7.0.0
epoch: 0
release: 1
summary: Deletes old files.
url: https://github.com/un1t/django-cleanup
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-54e135ef-6da4-420d-be04-d26814d54fc7
location_href: 00012089-python-django-cleanup/python-django-cleanup-7.0.0-1.src.rpm
checksum_type: sha256
description:
  The django-cleanup app automatically deletes files for :code:`FileField`, :code:`ImageField` and
  subclasses. When a :code:`FileField`'s value is changed and the model is saved, the old file is
  deleted. When a model that has a :code:`FileField` is deleted, the file is also deleted. A file that
  is set as the :code:`FileField`'s default value will not be deleted.


pkgId: 60428e4963cfb233e586b1796cf544feb97551f989f294c04195a16e0d8ec744
name: python-django-cms
arch: src
version: 3.11.1
epoch: 0
release: 1
summary: Lean enterprise content management powered by Django.
url: https://www.django-cms.org/
rpm_license: BSD-3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7c5025a9-4b17-4cf0-af84-cb7dd7ac19c9
location_href: 00012987-python-django-cms/python-django-cms-3.11.1-1.src.rpm
checksum_type: sha256
description:
  django CMS

  .. image:: https://travis-ci.org/django-cms/django-cms.svg?branch=develop
      :target: https://travis-ci.org/django-cms/django-cms
  .. image:: https://img.shields.io/pypi/v/django-cms.svg
      :target: https://pypi.python.org/pypi/django-cms/
  .. image:: https://img.shields.io/badge/wheel-yes-green.svg
      :target: https://pypi.python.org/pypi/django-cms/
  .. image:: https://img.shields.io/pypi/l/django-cms.svg
      :target: https://pypi.python.org/pypi/django-cms/
  .. image:: https://codeclimate.com/github/divio/django-cms/badges/gpa.svg
     :target: https://codeclimate.com/github/divio/django-cms
     :alt: Code Climate

  Open source enterprise content management system based on the Django framework and backed by the non-profit django CMS Association (`Sponsor us! <https://www.django-cms.org/en/memberships/>`_).

  *******************************************
  Contribute to this project and win rewards
  *******************************************

  Because django CMS is a community-driven project, we welcome everyone to `get involved in the project <https://www.django-cms.org/en/contribute/>`_ and `receive a reward <https://www.django-cms.org/en/bounty-program/>`_ for their contribution. Become part of a fantastic community and help us make django CMS the best open source CMS in the world.


  .. ATTENTION::

      Please use the ``develop`` branch as the target for pull requests for on-going development.

      Security fixes will be backported to older branches by the core team as appropriate.


  ********
  Features
  ********

  * hierarchical pages
  * extensive built-in support for multilingual websites
  * multi-site support
  * draft/publish workflows
  * version control
  * a sophisticated publishing architecture, that's also usable in your own applications
  * frontend content editing
  * a hierarchical content structure for nested plugins
  * an extensible navigation system that your own applications can hook into
  * SEO-friendly URLs
  * designed to integrate thoroughly into other applications

  Developing applications that integrate with and take advantage of django CMS features is easy and well-documented.

  More information on `our website <https://www.django-cms.org>`_.

  ************
  Requirements
  ************

  See the `Python/Django requirements for the current release version
  <http://docs.django-cms.org/en/latest/#software-version-requirements-and-release-notes>`_ in our documentation.

  See the `installation how-to guide for an overview of some other requirements and dependencies of the current release
  <http://docs.django-cms.org/en/latest/how_to/install.html>`_.


  ***************
  Getting started
  ***************

  These `tutorials <http://docs.django-cms.org/en/latest/introduction/index.html>`_ take you step-by-step through some key aspects of django CMS.


  *************
  Documentation
  *************

  Our documentation working group maintains documentation for several versions of the project. Key versions are:

  * `stable <http://docs.django-cms.org>`_ (default), for the **current release** version
  * `latest <http://docs.django-cms.org/en/latest/>`_, representing the latest build of the **release-3.4.x branch**
  * `develop <http://docs.django-cms.org/en/develop/>`_, representing the latest build of the **develop branch**

  For more information about our branch policy, see `Branches
  <http://docs.django-cms.org/en/latest/contributing/development-policies.html>`_.

  Our documentation is hosted courtesy of `Read the Docs <https://readthedocs.org>`_.

  The dependencies for the docs are compiled by `pip-tools <https://github.com/jazzband/pip-tools>`_.


  ***************************
  Test django CMS in our demo
  ***************************

  The demo platform is kindly provided by Divio, platinum member of the django CMS Association.

  .. image:: https://raw.githubusercontent.com/django-cms/django-cms/develop/docs/images/try-with-divio.png
     :target: https://www.django-cms.org/en/django-cms-demo/
     :alt: Try demo with Divio Cloud

  ************
  Getting Help
  ************

  Please head over to our `Slack channel <https://www.django-cms.org/slack>`_ or our `discourse forum <https://discourse.django-cms.org/>`_ for support.

  ********************
  Professional support
  ********************

  Choose from a list of `trusted tech partner <https://www.django-cms.org/en/tech-partners/>`_ of the django CMS Association to get your website project delivered successfully.

  Choose a `trusted web host <https://www.django-cms.org/en/hosting-services/>`_ for your django CMS project and get your website online today.


  **************************
  The django CMS Association
  **************************

  The django CMS Association is a non-profit organization that was founded in 2020 with the goal to drive the success of django CMS, by increasing customer happiness, market share and open-source contributions. We provide infrastructure and guidance for the django CMS project.

  The non-profit django CMS Association is dependent on donations to fulfill its purpose. The best way to donate is to become a member of the association and pay membership fees. The funding will be funneled back into core development and community projects.

  `Join the django CMS Association <https://www.django-cms.org/en/contribute/>`_.


  *******
  Credits
  *******

  * Includes icons from `FamFamFam <http://www.famfamfam.com>`_.
  * Python tree engine powered by
    `django-treebeard <https://tabo.pe/projects/django-treebeard/>`_.
  * JavaScript tree in admin uses `jsTree <https://www.jstree.com>`_.
  * Many thanks to
    `all the contributors <https://github.com/django-cms/django-cms/graphs/contributors>`_
    to django CMS!


pkgId: bedd5282e5d79d67ce7cee4cc3fd73b693210bdea5614c09c9ec6ec3a03283a4
name: python-django-colorfield
arch: src
version: 0.8.0
epoch: 0
release: 1
summary: simple color field for your models with a nice color-picker in the admin-interface.
url: https://github.com/fabiocaccamo/django-colorfield
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-576d9921-c7e8-4cd9-8119-28d84fa2fd71
location_href: 00011329-python-django-colorfield/python-django-colorfield-0.8.0-1.src.rpm
checksum_type: sha256
description:
  -   Run `pip install django-colorfield`
  -   Add `colorfield` to `settings.INSTALLED_APPS`
  -   Run `python manage.py collectstatic`


pkgId: 900464a1b714f99dd2b5fd593468862b8ca02787af53892f131abfddd814c99e
name: python-django-compat
arch: src
version: 1.0.15
epoch: 0
release: 1
summary: For- and backwards compatibility layer for Django 1.4, 1.7, 1.8, 1.9, 1.10, and 1.11
url: https://github.com/arteria/django-compat
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7640bbaa-9678-4376-9533-853a672f54c6
location_href: 00011346-python-django-compat/python-django-compat-1.0.15-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/arteria/django-compat.svg?branch=master)](https://travis-ci.org/arteria/django-compat)
  [![Stories in Ready](https://badge.waffle.io/arteria/django-compat.png?label=ready&title=Ready)](https://waffle.io/arteria/django-compat)
  [![Coverage Status](https://coveralls.io/repos/arteria/django-compat/badge.svg?branch=master&service=github)](https://coveralls.io/github/arteria/django-compat?branch=master)
  [![PyPI](https://img.shields.io/pypi/v/django-compat.svg)](https://pypi.python.org/pypi/django-compat)
  Forward and backwards compatibility layer for Django ~~1.4~~, ~~1.7~~, 1.8, 1.9, 1.10 and 1.11
  ~~Consider [django-compat](https://github.com/arteria/django-compat) as an experiment based on the discussion [on reddit](http://redd.it/2jrr4l). Let's see where it goes.~~
  What started as an experiment based on [this discussion on reddit](http://redd.it/2jrr4l) has proven to be true in real life.
  django-compat is under active development. To learn about other features, bug fixes, and changes, please refer to the [changelog](https://github.com/arteria/django-compat#changelog).

  Two popular examples of open source reusable app that uses django-compat are [django-hijack](https://github.com/arteria/django-hijack/) and [django-background-tasks](https://github.com/arteria/django-background-tasks).
  Want to have yours listed here? Send us a PR.

  * Be able to use the LTS versions of Django and support newer versions in your app
  * Use features from newer Django versions in an old one
  * Manage and master the gap between different framework versions

  Install compat from the [PyPI](https://pypi.python.org/pypi/django-compat) or download and install manually. All relevant  releases are listed [here under releases](https://github.com/arteria/django-compat/releases).
  Using one of the compatible objects is easy. For example
  	from compat import patterns, url
  	urlpatterns = patterns('ABC.views',
      		url(r'^abc/$', 'abc', name='abc-link'),
  See a full example [here](https://github.com/arteria/django-hijack/blob/4966d8865e7e829a562ff2724771628c6590f841/hijack/urls.py#L1).
  | django-compat is free software. If you find it useful and would like to give back, please consider to make a donation using [Bitcoin](https://blockchain.info/payment_request?address=1AJkbQdcNkrHzxi91mB1kkPxh4t4BJ4hu4) or [PayPal](https://www.paypal.me/arteriagmbh). Thank you! |
  | ----- |

  |Compatible object|Specifically tested|1.8|1.9|1.10|1.11|Notes|
  |---|---|---|---|---|---|---|
  |`BytesIO`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`DjangoJSONEncoder`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`EmailValidator`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`GenericForeignKey`|:heavy_multiplication_x:|:heavy_check_mark:|:x:|:x:|:x:||
  |`models.GenericForeignKey`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`HttpResponseBase`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`JsonResponse`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`LocaleRegexProvider`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`LocaleRegexURLResolver`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`NoReverseMatch`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`RegexURLPattern`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`RegexURLResolver`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`Resolver404`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`ResolverMatch`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`SortedDict`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`StringIO`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`URLValidator`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`VariableNode`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`View`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`add_to_builtins`|:heavy_multiplication_x:|:heavy_check_mark:|:x:|:x:|:x:||
  |`admin_utils`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`atomic`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`clean_manytomany_helptext`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`clear_url_caches`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`close_connection`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`commit`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`commit_on_success`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|`:heavy_check_mark:|`commit_on_success` replaced by `atomic` in Django >= 1.8|
  |`force_text`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`format_html`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_callable`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_current_site`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_ident`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_mod_func`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_model`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_model_name`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_ns_resolver`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_resolver`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_script_prefix`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_template_loaders`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_urlconf`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_user_model`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`get_username_field`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`handler404`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`handler500`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`import_module`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`import_string`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`include`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`is_valid_path`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`parse_qs`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`patterns`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:x:|:x:||
  |`python_2_unicode_compatible`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`render_to_string`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|The new function signature (https://docs.djangoproject.com/en/1.9/releases/1.8/#dictionary-and-context-instance-arguments-of-rendering-functions) is backported to pre-1.8.|
  |`resolve`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`resolve_url`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:warning:|:warning:|1.10: Reversing by dotted path has been removed|
  |`reverse`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`reverse_lazy`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`rollback`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|Transaction savepoint (sid) is required for Django < 1.8|
  |`set_script_prefix`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`set_urlconf`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`simplejson`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`slugify`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`smart_text`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`unquote_plus`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`url`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_multiplication_x:|:heavy_multiplication_x:|Function used in `urlpatterns`|
  |`tempat.url`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|Templatetag; import with `{% load url from compat %}`|
  |`uravy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`urlparse`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`urlresolvers`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`urlunparse`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`user_model_label`|:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:||
  |`templatetags.compat.verbatim`|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|Templatetag; import with `{% load verbatim from compat %}`. 1.4: Does not allow specific closing tags, e.g. `{% endverbatim myblock %}`, and does not preserve whitespace inside tags.|


  * https://github.com/ubernostrum/django-compat-lint
  * https://docs.djangoproject.com/en/dev/misc/api-stability/
  * https://docs.djangoproject.com/en/dev/topics/python3/
  * http://andrewsforge.com/presentation/upgrading-django-to-17/

  Bits and bites of the following projects were re-used to build [django-compat](https://github.com/arteria/django-compat).
  - [x] https://github.com/lukaszb/django-guardian/blob/devel/guardian/compat.py
  - [X] https://github.com/evonove/django-oauth-toolkit/blob/master/oauth2_provider/compat.py
  - [X] https://github.com/toastdriven/django-tastypie/blob/master/tastypie/compat.py
  - [X] https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/compat.py
  	- [ ] TODO: MinValueValidator, MaxValueValidator et al. (other relevant bits are included) Django 1.8
  - [X] https://gist.github.com/theskumar/ff8de60ff6a33bdacaa8
  - [X] https://github.com/evonove/django-oauth-toolkit/blob/master/oauth2_provider/templatetags/compat.py
  - [ ] https://github.com/kennethreitz/requests/blob/master/requests/compat.py
  - [ ] https://github.com/mitsuhiko/jinja2/blob/master/jinja2/_compat.py
  - [ ] https://github.com/jaraco/setuptools/blob/master/setuptools/compat.py
  - [ ] https://github.com/mariocesar/sorl-thumbnail/blob/master/sorl/thumbnail/compat.py


  * Update existing patches for Django 1.10

  * Update existing patches for Django 1.10

  * Add ``get_current_site`` and ``admin_utils``

  * Fix error when installing package under python 3.4

  * Backport new render_to_string function signature to Django < 1.8
  * Backport verbatim tag to Django 1.4
  * Add get_template_loaders
  * Add close_connection
  * Improve JsonResponse backport to Django 1.4
  * Add tests for import_module, get_model and add_to_builtins
  * Anticipate renaming of django.core.urlresolvers to django.urls in 1.10
  * Avoid warnings in setup.py

  * 1.9 compatibility for existing objects with the following changes:
  	* ``add_to_builtins`` was removed for Django >= 1.9
  	* ``GenericForeignKey` was moved to ``compat.models`` for Django >= 1.9

  * ``add_to_builtins`` was added

  * ``get_query_set``/``get_queryset`` support was dropped again (see [#29](https://github.com/arteria/django-compat/issues/29))


pkgId: 376a206e92da352768e5602fbdbc1353f8c21002e3efafe5197a242909d6b778
name: python-django-compressor
arch: src
version: 4.3.1
epoch: 0
release: 1
summary: ('Compresses linked and inline JavaScript or CSS into single cached files.',)
url: https://django-compressor.readthedocs.io/en/latest/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-82a7fb6c-7e69-49b6-9f85-6fe98fbda331
location_href: 00003454-python-django-compressor/python-django-compressor-4.3.1-1.src.rpm
checksum_type: sha256
description:
  Django Compressor processes, combines and minifies linked and inline
  Javascript or CSS in a Django template into cacheable static files.
  It supports compilers such as coffeescript, LESS and SASS and is
  extensible by custom processing steps.


pkgId: 30a69e95cc91eb8a78389dc66812946239bc055b1024c515e42b936032b430ea
name: python-django-configurations
arch: src
version: 2.4
epoch: 0
release: 1
summary: A helper for organizing Django settings.
url: https://django-configurations.readthedocs.io/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f80f01e6-8a3a-4761-90c1-742e9422b411
location_href: 00003455-python-django-configurations/python-django-configurations-2.4-1.src.rpm
checksum_type: sha256
description:
  |jazzband| |build-status| |codecov| |docs| |python-support| |django-support|
  django-configurations eases Django project configuration by relying
  on the composability of Python classes. It extends the notion of
  Django's module based settings loading with well established
  object oriented programming patterns.
  Check out the `documentation`_ for more complete examples.


pkgId: 9e0dd252a0a95ea90e7ec4fe987018c27fa98d64aacd786ffdfec593b853efaf
name: python-django-constance
arch: src
version: 2.9.1
epoch: 0
release: 1
summary: Django live settings with pluggable backends, including Redis.
url: https://github.com/jazzband/django-constance
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9de6dc08-505c-418d-8772-3506d76f3c49
location_href: 00011134-python-django-constance/python-django-constance-2.9.1-1.src.rpm
checksum_type: sha256
description:
  A Django app for storing dynamic settings in pluggable backends (Redis and
  Django model backend built in) with an integration with the Django admin app.
  For more information see the documentation at:
  https://django-constance.readthedocs.io/
  If you have questions or have trouble using the app please file a bug report
  at:
  https://github.com/jazzband/django-constance/issues


pkgId: 49f35248bbe02c8a8fd4b686f2d9f0b8c36bd1b4b87b928f1caab294de3240ae
name: python-django-contact-form
arch: src
version: 2.0.1
epoch: 0
release: 1
summary: A generic contact-form application for Django
url: https://github.com/ubernostrum/django-contact-form/
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-eeca20ac-c0a5-4682-ac33-8278ed6b8e9e
location_href: 00003456-python-django-contact-form/python-django-contact-form-2.0.1-1.src.rpm
checksum_type: sha256
description:
  .. -*-restructuredtext-*-

  .. image:: https://github.com/ubernostrum/django-contact-form/workflows/CI/badge.svg
     :alt: CI status image
     :target: https://github.com/ubernostrum/django-contact-form/actions?query=workflow%3ACI

  This application provides extensible contact-form functionality for
  `Django <https://www.djangoproject.com/>`_ sites.

  Full documentation for all functionality is included and is also
  `available online <http://django-contact-form.readthedocs.io/>`_.


pkgId: 8fc749795bfe36151ec765cae4f6272fbf5e71450cb78485ac721c4bca31fcb7
name: python-django-cors-headers
arch: src
version: 3.14.0
epoch: 0
release: 1
url: https://github.com/adamchainz/django-cors-headers
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e570fcfd-0760-4d53-be87-aeaaf7c121bf
location_href: 00003458-python-django-cors-headers/python-django-cors-headers-3.14.0-1.src.rpm
checksum_type: sha256
summary:
  django-cors-headers is a Django application for handling the server headers required for Cross-Origin Resource Sharing (CORS).


pkgId: 3f3c84ee1778bdb90b19e9cf5bca7ee496a5e4b7e8c160df96d140e79add7587
name: python-django-crum
arch: src
version: 0.7.9
epoch: 0
release: 1
summary: Django middleware to capture current request and user.
url: https://github.com/ninemoreminutes/django-crum/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1aa2e96d-907b-4f81-b56f-68a7a7a502a1
location_href: 00012374-python-django-crum/python-django-crum-0.7.9-1.src.rpm
checksum_type: sha256
description:
  Django-CRUM (Current Request User Middleware) captures the current request and
  user in thread local storage.
  It enables apps to check permissions, capture audit trails or otherwise access
  the current request and user without requiring the request object to be passed
  directly. It also offers a context manager to allow for temporarily
  impersonating another user.
  It provides a signal to extend the built-in function for getting the current
  user, which could be helpful when using custom authentication methods or user
  models.
  Documentation can be found at `RTFD <http://django-crum.readthedocs.io/>`_.
  It is tested against:
   * Django 1.11 (Python 3.5 and 3.6)
   * Django 2.0 (Python 3.5, 3.6 and 3.7)
   * Django 2.1 (Python 3.5, 3.6 and 3.7)
   * Django 2.2 (Python 3.5, 3.6, 3.7, 3.8 and 3.9)
   * Django 3.0 (Python 3.6, 3.7, 3.8 and 3.9)
   * Django 3.1 (Python 3.6, 3.7, 3.8 and 3.9)
   * Django master/3.2 (Python 3.6, 3.7, 3.8 and 3.9)


pkgId: 3bebfc36cd20b13ae0a86f31d24c201eab901ce8794a72aeba7c17c901db489c
name: python-django-database-url
arch: src
version: 1.0.3
epoch: 0
release: 1
summary: Use Database URLs in your Django Application.
url: https://github.com/tend/dj-database-url
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-3aad24fd-f561-4139-a692-5edc8b8f1ae3
location_href: 00003460-python-django-database-url/python-django-database-url-1.0.3-1.src.rpm
checksum_type: sha256
description:
  Support currently exists for PostgreSQL, PostGIS, MySQL, MySQL (GIS),
  Oracle, Oracle (GIS), Redshift, and SQLite.


pkgId: 6a0be6422d26abe66fd16c6749b6c50ce7d112286eeaf5a8b8dbe84e5abd9749
name: python-django-debreach
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: Adds middleware to give some added protection against the BREACH attack in Django.
url: http://github.com/lpomfrey/django-debreach
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fa1ca5f4-34c7-408f-ac1b-5684a9d43e9c
location_href: 00003461-python-django-debreach/python-django-debreach-2.1.0-1.src.rpm
checksum_type: sha256
description:
  Extra mitigation against the `BREACH attack <http://breachattack.com/>`_
  for Django projects.
  django-debreach provides additional protection to Django's built in CSRF
  token masking by randomising the content length of each response. This is
  achieved by adding a random string of between 12 and 25 characters as a
  comment to the end of the HTML content. Note that this will only be applied to
  responses with a content type of ``text/html``.
  When combined with the built-in mitigations in Django and rate limiting
  (either in your web-server, or by using something like
  `django-ratelimit <http://django-ratelimit.readthedocs.org/>`_), the
  techniques here should provide a fairly comprehensive protection against the
  BREACH attack.


pkgId: d69398187704ce6b579df77f2da0bf777346b106ecfb0c1becf4daaf30285e4f
name: python-django-environ
arch: src
version: 0.10.0
epoch: 0
release: 1
url: https://django-environ.readthedocs.org
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-38fb8773-21ea-4514-aecb-c4bb408e3f70
location_href: 00009688-python-django-environ/python-django-environ-0.10.0-1.src.rpm
checksum_type: sha256
summary:
  A package that allows you to utilize 12factor inspired environment variables to configure your Django application.


pkgId: e8dbc1622cca5be7bc0c51cb1b41512b3f749b68d5a85db6280b329f248c8359
name: python-django-extra-fields
arch: src
version: 3.0.2
epoch: 0
release: 1
summary: Additional fields for Django Rest Framework.
url: https://github.com/Hipo/drf-extra-fields
rpm_license: Apache-2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-579e01e3-88e1-4f35-a78f-bc495df527f1
location_href: 00012146-python-django-extra-fields/python-django-extra-fields-3.0.2-1.src.rpm
checksum_type: sha256
description:
  This package renamed as "drf-extra-fields", earlier it was named as django-extra-fields. New versions can be tracked from [here](https://github.com/Hipo/drf-extra-fields).


pkgId: 587a468011dd4c5de55d3b995704cde28be3e22c21cefba7673f17364d028425
name: python-django-extra-views
arch: src
version: 0.14.0
epoch: 0
release: 1
summary: Extra class-based views for Django
url: https://github.com/AndrewIngram/django-extra-views
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e1cd0c9d-9ea8-411e-b3ce-1dfc3b02d828
location_href: 00012629-python-django-extra-views/python-django-extra-views-0.14.0-1.src.rpm
checksum_type: sha256
description:
  Django-extra-views is a Django package which introduces additional class-based views
  in order to simplify common design patterns such as those found in the Django
  admin interface.
  Full documentation is available at `read the docs`_.


pkgId: 0e238d9c9eef3dcd39f4d1f533d3cd2b9ab67990585dd20e205720f720c10965
name: python-django-filter
arch: src
version: 22.1
epoch: 0
release: 1
summary: Django-filter is a reusable Django application for allowing users to filter querysets dynamically.
url: https://github.com/carltongibson/django-filter/tree/main
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c06ae174-a721-4afa-8513-fcd7ae9044a8
location_href: 00003465-python-django-filter/python-django-filter-22.1-1.src.rpm
checksum_type: sha256
description:
  Django-filter is a reusable Django application allowing users to declaratively
  add dynamic ``QuerySet`` filtering from URL parameters.
  Full documentation on `read the docs`_.


pkgId: f3d295fc6e74649a4d1be28e253818ba87b1157a8cd65832d4bb661af99f2674
name: python-django-graphql-jwt
arch: src
version: 0.3.4
epoch: 0
release: 1
summary: JSON Web Token for Django GraphQL.
url: https://github.com/flavors/django-graphql-jwt
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c071272f-abe5-4846-8916-c2d085471f1c
location_href: 00011687-python-django-graphql-jwt/python-django-graphql-jwt-0.3.4-1.src.rpm
checksum_type: sha256
description:
  <p align="center">
    <a href="https://django-graphql-jwt.domake.io/"><img width="420px" src="https://django-graphql-jwt.domake.io/_static/logo.png" alt='Django GraphQL JWT'></a>
  </p>

  <p align="center">
      JSON Web Token authentication for Django GraphQL.
      <br>Fantastic <strong>documentation</strong> is available at <a href="https://django-graphql-jwt.domake.io">https://django-graphql-jwt.domake.io</a>.
  </p>
  <p align="center">
      <a href="https://github.com/flavors/django-graphql-jwt/actions">
          <img src="https://github.com/flavors/django-graphql-jwt/actions/workflows/test-suite.yml/badge.svg" alt="Test">
      </a>
      <a href="https://codecov.io/gh/flavors/django-graphql-jwt">
          <img src="https://img.shields.io/codecov/c/github/flavors/django-graphql-jwt?color=%2334D058" alt="Coverage">
      </a>
      <a href="https://www.codacy.com/gh/flavors/django-graphql-jwt/dashboard">
          <img src="https://app.codacy.com/project/badge/Grade/4f9fd439fbc74be88a215b9ed2abfcf9" alt="Codacy">
      </a>
      <a href="https://pypi.python.org/pypi/django-graphql-jwt">
          <img src="https://img.shields.io/pypi/v/django-graphql-jwt.svg" alt="Package version">
      </a>
  </p>



  Install last stable version from Pypi:

  ```sh
  pip install django-graphql-jwt
  ```

  Add `AuthenticationMiddleware` middleware to your *MIDDLEWARE* settings:


  ```py
  MIDDLEWARE = [
      
      "django.contrib.auth.middleware.AuthenticationMiddleware",
      
  ]
  ```

  Add `JSONWebTokenMiddleware` middleware to your *GRAPHENE* settings:

  ```py
  GRAPHENE = {
      "SCHEMA": "mysite.myschema.schema",
      "MIDDLEWARE": [
          "graphql_jwt.middleware.JSONWebTokenMiddleware",
      ],
  }
  ```

  Add `JSONWebTokenBackend` backend to your *AUTHENTICATION_BACKENDS*:

  ```py
  AUTHENTICATION_BACKENDS = [
      "graphql_jwt.backends.JSONWebTokenBackend",
      "django.contrib.auth.backends.ModelBackend",
  ]
  ```



  Add *django-graphql-jwt* mutations to the root schema:

  ```py
  import graphene
  import graphql_jwt


  class Mutation(graphene.ObjectType):
      token_auth = graphql_jwt.ObtainJSONWebToken.Field()
      verify_token = graphql_jwt.Verify.Field()
      refresh_token = graphql_jwt.Refresh.Field()


  schema = graphene.Schema(mutation=Mutation)
  ```


pkgId: a902e139f8d51dc85ef0b4541a067ea18d04af862ae585d9c45dcdbaacd344ba
name: python-django-grappelli
arch: src
version: 3.0.5
epoch: 0
release: 1
summary: A jazzy skin for the Django Admin-Interface.
url: http://django-grappelli.readthedocs.org
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-77b521c6-dc7a-4468-8287-cecbc9563a6b
location_href: 00011256-python-django-grappelli/python-django-grappelli-3.0.5-1.src.rpm
checksum_type: sha256
description:
  **A jazzy skin for the Django admin interface**.
  Grappelli is a grid-based alternative/extension to the `Django <http://www.djangoproject.com>`_ administration interface.


pkgId: 8df7e7475d11aa0187102c2c0aee2eb4441a2ff85cffe8efa530c0a2836f2a5c
name: python-django-hashid-field
arch: src
version: 3.3.7
epoch: 0
release: 1
summary: A Hashids obfuscated Django Model Field
url: https://github.com/nshafer/django-hashid-field
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1f0a54f8-dde1-4faf-b2a3-255743f74af9
location_href: 00013476-python-django-hashid-field/python-django-hashid-field-3.3.7-1.src.rpm
checksum_type: sha256
description:
  A custom Model Field that uses the `Hashids <http://hashids.org/>`_ `library <https://pypi.python.org/pypi/hashids/>`_
  to obfuscate an IntegerField or AutoField. It can be used in new models or dropped in place of an existing IntegerField,
  explicit AutoField, or an automatically generated AutoField.


pkgId: 711e93aa015b5269a4fe1f7553b03b40cf605f1973324a71c6bce2c65aa38afd
name: python-django-helpdesk
arch: src
version: 0.4.1
epoch: 0
release: 1
summary: Django-powered ticket tracker for your helpdesk
url: https://github.com/django-helpdesk/django-helpdesk
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f4071ee6-2426-4a42-84e8-3d5dc7a38a42
location_href: 00003470-python-django-helpdesk/python-django-helpdesk-0.4.1-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://dev.azure.com/django-helpdesk/django-helpdesk/_apis/build/status/django-helpdesk.django-helpdesk?branchName=master)](https://dev.azure.com/django-helpdesk/django-helpdesk/_build/latest?definitionId=1&branchName=master)
  Copyright 2009-2022 Ross Poulton and django-helpdesk contributors. All Rights Reserved.
  See LICENSE for details.
  django-helpdesk was formerly known as Jutda Helpdesk, named after the
  company which originally created it. As of January 2011 the name has been
  changed to reflect what it really is: a Django-powered ticket tracker with
  contributors reaching far beyond Jutda.
  Complete documentation is available in the docs/ directory,
  or online at http://django-helpdesk.readthedocs.org/.
  You can see a demo installation at https://django-helpdesk-demo.herokuapp.com/,
  or run a demo locally in just a couple steps!


pkgId: 3de4fcad9dcb7a04b8a3b04b45ea8ce95f7fab73338c4b872cdc6b7cd3ca017a
name: python-django-heroku
arch: src
version: 0.3.1
epoch: 0
release: 1
summary: This is a Django library for Heroku apps.
url: https://github.com/heroku/django-heroku
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-42256857-e6fb-4b25-b777-b636969b2778
location_href: 00011268-python-django-heroku/python-django-heroku-0.3.1-1.src.rpm
checksum_type: sha256
description:
  This is a Django library for Heroku applications that ensures a seamless deployment and development experience.
  This library provides:
  -  Settings configuration (Static files / WhiteNoise).
  -  Logging configuration.


pkgId: 8b239a47da4e7dc4800bab5dc4bf43e07fdc5e3e2828c564de6ca79ae5acdc55
name: python-django-hosts
arch: src
version: 5.2
epoch: 0
release: 1
summary: Dynamic and static host resolving for Django. Maps hostnames to URLconfs.
url: https://django-hosts.readthedocs.io/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-50e759a2-d241-474f-bdc0-50d85821cb7e
location_href: 00011487-python-django-hosts/python-django-hosts-5.2-1.src.rpm
checksum_type: sha256
description:
  This Django app routes requests for specific hosts to different URL schemes
  defined in modules called "hostconfs".
  For example, if you own ``example.com`` but want to serve specific content
  at ``api.example.com`` and ``beta.example.com``, add the following to a
  ``hosts.py`` file:
      from django_hosts import patterns, host
      host_patterns = patterns('path.to',
          host(r'api', 'api.urls', name='api'),
          host(r'beta', 'beta.urls', name='beta'),
      )
  This causes requests to ``{api,beta}.example.com`` to be routed to their
  corresponding URLconf. You can use your ``urls.py`` as a template for these
  hostconfs.
  Patterns are evaluated in order. If no pattern matches, the request is
  processed in the usual way, ie. using the standard ``ROOT_URLCONF``.
  The patterns on the left-hand side are regular expressions. For example,
  the following ``ROOT_HOSTCONF`` setting will route ``foo.example.com``
  and ``bar.example.com`` to the same URLconf.
      from django_hosts import patterns, host
      host_patterns = patterns('',
          host(r'(foo|bar)', 'path.to.urls', name='foo-or-bar'),
      )
    Remember:
    * Patterns are matched against the extreme left of the requested host
    * It is implied that all patterns end either with a literal full stop
      (ie. ".") or an end of line metacharacter.
    * As with all regular expressions, various metacharacters need quoting.


pkgId: 4a78263f06d01efc7c651877586c12fd8f72e1ad2de6fdb8d6681f2880092ec3
name: python-django-imagekit
arch: src
version: 4.1.0
epoch: 0
release: 1
summary: Automated image processing for Django models.
url: http://github.com/matthewwithanm/django-imagekit/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-439fe738-8ea5-4345-877d-d9e24407ccde
location_href: 00011602-python-django-imagekit/python-django-imagekit-4.1.0-1.src.rpm
checksum_type: sha256
description:
  1. Install `Pillow`_. (If you're using an ``ImageField`` in Django,
     you should have already done this.)
  2. ``pip install django-imagekit``
  3. Add ``'imagekit'`` to your ``INSTALLED_APPS`` list in your project's ``settings.py``


pkgId: 6e04e460884ded7365db4e4213e8b12bc61f52861b4aa0a1f1712358f7e2fe3f
name: python-django-impersonate
arch: src
version: 1.9.1
epoch: 0
release: 1
summary: Django app to allow superusers to impersonate other users.
url: https://code.netlandish.com/~petersanchez/django-impersonate
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-00aae797-8595-4282-ae16-2d0b65b8dbc4
location_href: 00012643-python-django-impersonate/python-django-impersonate-1.9.1-1.src.rpm
checksum_type: sha256
description:
  Simple application to allow superusers to "impersonate" other
  non-superuser accounts.
  **Version:** 1.9.1
  **Project Links:**
  `Issues <https://todo.code.netlandish.com/~petersanchez/django-impersonate>`__
  - `Mailing
  List <https://lists.code.netlandish.com/~petersanchez/public-inbox>`__ -
  `Contributing <#contributing>`__
  **Author:** Peter Sanchez (https://petersanchez.com)


pkgId: 386cdb620a3da3761d9bcb64a8b8ae5ede591528e0bbe5f90dd413798c8d3f4b
name: python-django-ipware
arch: src
version: 5.0.0
epoch: 0
release: 1
summary: A Django application to retrieve user's IP address
url: https://github.com/un33k/django-ipware
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ff2f36a8-ff7f-4a65-8efa-28167b511d1b
location_href: 00003471-python-django-ipware/python-django-ipware-5.0.0-1.src.rpm
checksum_type: sha256
description:
  **A Django application to retrieve client's IP address**

  [![status-image]][status-link]
  [![version-image]][version-link]
  [![coverage-image]][coverage-link]



  **Best attempt** to get client's IP address while keeping it **DRY**.



  There is no perfect `out-of-the-box` solution against fake IP addresses, aka `IP Address Spoofing`.
  You are encouraged to read the ([Advanced users](README.md#advanced-users)) section of this page and
  use `trusted_proxies_ips` and/or `proxy_count` features to match your needs, especially `if` you are
  planning to include `ipware` in any authentication, security or `anti-fraud` related architecture.

  This is an open source project, with the source code visible to all. Therefore, it may be exploited through unimplemented, or improperly implemented features.

  Please use ipware `ONLY` as a complement to your `firewall` security measures!



      1. easy_install django-ipware
      2. pip install django-ipware
      3. git clone http://github.com/un33k/django-ipware
          a. cd django-ipware
          b. run python setup.py install
      4. wget https://github.com/un33k/django-ipware/zipball/master
          a. unzip the downloaded file
          b. cd into django-ipware-* directory
          c. run python setup.py install



  ```python
   

   from ipware import get_client_ip
   client_ip, is_routable = get_client_ip(request)
   if client_ip is None:
      
   else:
       
       if is_routable:
           
       else:
           

   
  ```



  - ### Precedence Order

    The default meta precedence order is top to bottom. However, you may customize the order
    by providing your own `IPWARE_META_PRECEDENCE_ORDER` by adding it to your project's settings.py

    ```python
     
     IPWARE_META_PRECEDENCE_ORDER = (
         'HTTP_X_FORWARDED_FOR', 'X_FORWARDED_FOR',  # <client>, <proxy1>, <proxy2>
         'HTTP_CLIENT_IP',
         'HTTP_X_REAL_IP',
         'HTTP_X_FORWARDED',
         'HTTP_X_CLUSTER_CLIENT_IP',
         'HTTP_FORWARDED_FOR',
         'HTTP_FORWARDED',
         'HTTP_VIA',
         'REMOTE_ADDR',
     )
    ```

    **Alternatively**, you can provide your custom _request header meta precedence order_ when calling `get_client_ip()`.

  ```python
  get_client_ip(request, request_header_order=['X_FORWARDED_FOR'])
  get_client_ip(request, request_header_order=['X_FORWARDED_FOR', 'HTTP_X_FORWARDED_FOR'])
  ```



  You may customize the prefixes to indicate an IP address is private. This is done by adding your
  own `IPWARE_PRIVATE_IP_PREFIX` to your project's settings.py. IP addresses matching the following
  prefixes are considered _private_ & are **not** publicly routable.

  ```python

  IPWARE_PRIVATE_IP_PREFIX = getattr(settings,
     'IPWARE_PRIVATE_IP_PREFIX', (
       '0.',  # messages to software
       '10.',  # class A private block
       '100.64.',  '100.65.',  '100.66.',  '100.67.',  '100.68.',  '100.69.',
       '100.70.',  '100.71.',  '100.72.',  '100.73.',  '100.74.',  '100.75.',
       '100.76.',  '100.77.',  '100.78.',  '100.79.',  '100.80.',  '100.81.',
       '100.82.',  '100.83.',  '100.84.',  '100.85.',  '100.86.',  '100.87.',
       '100.88.',  '100.89.',  '100.90.',  '100.91.',  '100.92.',  '100.93.',
       '100.94.',  '100.95.',  '100.96.',  '100.97.',  '100.98.',  '100.99.',
       '100.100.', '100.101.', '100.102.', '100.103.', '100.104.', '100.105.',
       '100.106.', '100.107.', '100.108.', '100.109.', '100.110.', '100.111.',
       '100.112.', '100.113.', '100.114.', '100.115.', '100.116.', '100.117.',
       '100.118.', '100.119.', '100.120.', '100.121.', '100.122.', '100.123.',
       '100.124.', '100.125.', '100.126.', '100.127.',  # carrier-grade NAT
       '169.254.',  # link-local block
       '172.16.', '172.17.', '172.18.', '172.19.',
       '172.20.', '172.21.', '172.22.', '172.23.',
       '172.24.', '172.25.', '172.26.', '172.27.',
       '172.28.', '172.29.', '172.30.', '172.31.',  # class B private blocks
       '192.0.0.',  # reserved for IANA special purpose address registry
       '192.0.2.',  # reserved for documentation and example code
       '192.168.',  # class C private block
       '198.18.', '198.19.',  # reserved for inter-network communications between two separate subnets
       '198.51.100.',  # reserved for documentation and example code
       '203.0.113.',  # reserved for documentation and example code
       '224.', '225.', '226.', '227.', '228.', '229.', '230.', '231.', '232.',
       '233.', '234.', '235.', '236.', '237.', '238.', '239.',  # multicast
       '240.', '241.', '242.', '243.', '244.', '245.', '246.', '247.', '248.',
       '249.', '250.', '251.', '252.', '253.', '254.', '255.',  # reserved
     ) + (
       '::',  # Unspecified address
       '::ffff:', '2001:10:', '2001:20:'  # messages to software
       '2001::',  # TEREDO
       '2001:2::',  # benchmarking
       '2001:db8:',  # reserved for documentation and example code
       'fc00:',  # IPv6 private block
       'fe80:',  # link-local unicast
       'ff00:',  # IPv6 multicast
     )
  )
  ```



  If your Django server is behind one or more known proxy server(s), you can filter out unwanted requests
  by providing the `trusted` proxy list when calling `get_client_ip(request, proxy_trusted_ips=['177.139.233.133'])`.
  In the following example, your load balancer (LB) can be seen as a `trusted` proxy.

  ```
   `Real` Client  <public> <---> <public> LB (Server) <private> <--------> <private> Django Server
                                                                     ^
                                                                     |
   `Fake` Client  <private> <---> <private> LB (Server) <private> ---^
  ```

  ```python

  client_ip, is_routable = get_client_ip(request, proxy_trusted_ips=['177.139.233.133'])


  client_ip, is_routable = get_client_ip(request, proxy_trusted_ips=['177.139.233.133', '177.139.233.134'])


  client_ip, is_routable = get_client_ip(request, proxy_trusted_ips=['177.139.', '177.140'])
  client_ip, is_routable = get_client_ip(request, proxy_trusted_ips=['177.139.233.', '177.139.240'])
  ```

  `Please note:` By default, the `right-most` proxy in the chain is the `trusted` proxy and that is the one your django
  server talks to. Therefore, `ipware` checks to see if the `right-most` proxy address starts with any ip pattern that was
  passed in via the `proxy_trusted_ips` list.



  If your Django server is behind a `known` number of proxy server(s), you can filter out unwanted requests
  by providing the `number` of proxies when calling `get_client_ip(request, proxy_count=1)`.
  In the following example, your load balancer (LB) can be seen as the `only` proxy.

  ```
   `Real` Client  <public> <---> <public> LB (Server) <private> <--------> <private> Django Server
                                                                     ^
                                                                     |
                                         `Fake` Client  <private> ---^
  ```

  ```python

  client_ip, is_routable = get_client_ip(request, proxy_count=1)



  client_ip, is_routable = get_client_ip(request, proxy_count=1, proxy_trusted_ips=['177.139.233.133'])
  ```



  If your proxy server is configured such that the right-most IP address is that of the originating client, you
  can indicate `right-most` as your `proxy_order` when calling `get_client_ip(request, proxy_order="right-most")`.
  Please note that the [de-facto](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For) standard
  for the originating client IP address is the `left-most` as per `<client>, <proxy1>, <proxy2>`.



  To run the tests against the current environment:

      python manage.py test



  Released under a ([MIT](LICENSE)) license.



  X.Y.Z Version

      `MAJOR` version -- when you make incompatible API changes,
      `MINOR` version -- when you add functionality in a backwards-compatible manner, and
      `PATCH` version -- when you make backwards-compatible bug fixes.

  [status-image]: https://travis-ci.org/un33k/django-ipware.svg?branch=master
  [status-link]: https://travis-ci.org/un33k/django-ipware
  [version-image]: https://img.shields.io/pypi/v/django-ipware.svg
  [version-link]: https://pypi.python.org/pypi/django-ipware
  [coverage-image]: https://coveralls.io/repos/un33k/django-ipware/badge.svg
  [coverage-link]: https://coveralls.io/r/un33k/django-ipware
  [download-image]: https://img.shields.io/pypi/dm/django-ipware.svg
  [download-link]: https://pypi.python.org/pypi/django-ipware



  [Neekware Inc.](http://neekware.com)


pkgId: eee80ce965567b13a32f958542e46ec19c7ac5a329685a240396452472fb8a29
name: python-django-jinja
arch: src
version: 2.10.2
epoch: 0
release: 1
summary: Jinja2 templating language integrated in Django.
url: https://github.com/niwinz/django-jinja
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7f8d4881-1bfa-49cd-a7e3-7e3e717e5909
location_href: 00012002-python-django-jinja/python-django-jinja-2.10.2-1.src.rpm
checksum_type: sha256
description:
  Simple and nonobstructive jinja2 integration with Django.
  **Documentation:** http://niwinz.github.io/django-jinja/latest/


pkgId: 5e610b434441af3c87742b57cf9283e3b867db614b8e973c0d3d9fc3f9a1cbe5
name: python-django-json-widget
arch: src
version: 1.1.1
epoch: 0
release: 1
url: https://github.com/jmrivas86/django-json-widget
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2a853b18-507b-44ae-878c-2c6aa148650c
location_href: 00011330-python-django-json-widget/python-django-json-widget-1.1.1-1.src.rpm
checksum_type: sha256
summary:
  Django json widget is an alternative widget that makes it easy to edit the jsonfield field of django.


pkgId: 386e6d4128f0a06e1bd049d07193ca03685f72bacb76d7c639bd417596bd2e4e
name: python-django-jsonfield
arch: src
version: 1.4.1
epoch: 0
release: 1
summary: JSONField for django models
url: https://github.com/adamchainz/django-jsonfield
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b4e95221-e40d-483a-aca8-c9d261110a8b
location_href: 00011219-python-django-jsonfield/python-django-jsonfield-1.4.1-1.src.rpm
checksum_type: sha256
description:
  **Maintenance mode only:** It is not recommended you use this library on new
  projects. Django 3.1 includes a cross-database ``JSONField`` implementation -
  see its `release notes <https://docs.djangoproject.com/en/3.1/releases/3.1/#jsonfield-for-all-supported-database-backends>`__.
  You can use that field on older versions of Django with the
  `django-jsonfield-backport <https://pypi.org/project/django-jsonfield-backport/>`__
  package. See the (long) **History** section below for more information.
  **Naming clarification:** This project is released on Pypi under the name
  `django-jsonfield <https://pypi.org/project/django-jsonfield/>`_.
  It should not be confused with the Pypi package
  `jsonfield <https://pypi.org/project/jsonfield/>`_,


pkgId: 509b7080934dfabdff6e0c6131e773d500e69cc32baad5ae59c30b5f230d930d
name: python-django-log-request-id
arch: src
version: 2.1.0
epoch: 0
release: 1
url: https://github.com/dabapps/django-log-request-id/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-049e3844-ff08-4c8a-b37d-cc4016080316
location_href: 00010650-python-django-log-request-id/python-django-log-request-id-2.1.0-1.src.rpm
checksum_type: sha256
summary:
  Django middleware and log filter to attach a unique ID to every log message generated as part of a request

description:
  **Django middleware and log filter to attach a unique ID to every log message generated as part of a request.**
  **Author:** Jamie Matthews, [@j4mie](https://twitter.com/j4mie)
  [![Build Status](https://travis-ci.org/dabapps/django-log-request-id.png?branch=master)](https://travis-ci.org/dabapps/django-log-request-id)


pkgId: 6e688e11715de77baa2bfc6652715317aabfb45a35d6f2dd6e640d5d057d9333
name: python-django-macros
arch: src
version: 0.4.0
epoch: 0
release: 1
summary: A Django template tag library for repeating blocks tags and creating in template macros.
url: https://github.com/nalourie/django-macros
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-31327bd8-3178-4cbd-8434-e1415cd9f090
location_href: 00003473-python-django-macros/python-django-macros-0.4.0-1.src.rpm
checksum_type: sha256
description:
  Macros accepting positional and keyword arguments, and repeated block
  tags in the django template system. Sometimes include tags just don't
  get the job done. Either you have repeated code that you want to keep
  all in the same single template, or your code needs to dynamically
  generate and sub in certain values, in a way that the include syntax
  inhibits. Whatever the case, if you're finding that the built in include
  tag just isn't working for your use case, then perhaps django-macros is
  for you.
  visit the `github <https://github.com/nalourie/django-macros>`__.


pkgId: abc8596f539da6ec225c796f01af7a9f9d23da5284f85d4c4ff2b75c354ce3d0
name: python-django-mailbox
arch: src
version: 4.8.2
epoch: 0
release: 1
url: http://github.com/coddingtonbear/django-mailbox/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-572ac0b3-dea8-4c03-81ac-a6a7d0ce2b52
location_href: 00013559-python-django-mailbox/python-django-mailbox-4.8.2-1.src.rpm
checksum_type: sha256
summary:
  Import mail from POP3, IMAP, local mailboxes or directly from Postfix or Exim4 into your Django application automatically.


pkgId: 6dd8862aab3889fb13ae7ae8f3aa7592a596ab981eaf587440243e792e9e2542
name: python-django-memoize
arch: src
version: 2.3.1
epoch: 0
release: 1
summary: An implementation of memoization technique for Django.
url: https://github.com/unhaggle/django-memoize
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f547d155-30b7-4683-8bac-8cf1f8422fcf
location_href: 00013566-python-django-memoize/python-django-memoize-2.3.1-1.src.rpm
checksum_type: sha256
description:
  **django-memoize** is an implementation
  of `memoization <http://en.wikipedia.org/wiki/Memoization>`_ technique
  for Django. You can think of it as a cache for function or method results.


pkgId: 07bd76711dcfcb9581e23940503502f53100ddf63d87cf22704d05dd6493943f
name: python-django-migration-linter
arch: src
version: 4.1.0
epoch: 0
release: 1
summary: Detect backward incompatible migrations for your django project
url: https://github.com/3YOURMIND/django-migration-linter
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-69821bf4-c77c-4a9b-88c8-e73e460c3177
location_href: 00011506-python-django-migration-linter/python-django-migration-linter-4.1.0-1.src.rpm
checksum_type: sha256
description:
  Detect backward incompatible migrations for your Django project.
  It will save you time by making sure migrations will not break with a older codebase.

  [![Build Status](https://img.shields.io/endpoint.svg?url=https%3A%2F%2Factions-badge.atrox.dev%2F3YOURMIND%2Fdjango-migration-linter%2Fbadge%3Fref%3Dmain&style=flat)](https://actions-badge.atrox.dev/3YOURMIND/django-migration-linter/goto?ref=main)
  [![codecov](https://codecov.io/gh/3YOURMIND/django-migration-linter/branch/master/graph/badge.svg?token=pgNNXGbCf7)](https://codecov.io/gh/3YOURMIND/django-migration-linter)
  [![PyPI](https://img.shields.io/pypi/v/django-migration-linter.svg)](https://pypi.python.org/pypi/django-migration-linter/)
  [![PR_Welcome](https://img.shields.io/badge/PR-welcome-green.svg)](https://github.com/3YOURMIND/django-migration-linter/pulls)
  [![3YD_Hiring](https://img.shields.io/badge/3YOURMIND-Hiring-brightgreen.svg)](https://www.3yourmind.com/career)
  [![GitHub_Stars](https://img.shields.io/github/stars/3YOURMIND/django-migration-linter.svg?style=social&label=Stars)](https://github.com/3YOURMIND/django-migration-linter/stargazers)



  ```
  pip install django-migration-linter
  ```

  And add the migration linter your ``INSTALLED_APPS``:
  ```
      INSTALLED_APPS = [
          ...,
          "django_migration_linter",
          ...,
      ]
  ```



  ```
  $ python manage.py lintmigrations

  (app_add_not_null_column, 0001_create_table)... OK
  (app_add_not_null_column, 0002_add_new_not_null_field)... ERR
          NOT NULL constraint on columns
  (app_drop_table, 0001_initial)... OK
  (app_drop_table, 0002_delete_a)... ERR
          DROPPING table
  (app_ignore_migration, 0001_initial)... OK
  (app_ignore_migration, 0002_ignore_migration)... IGNORE
  (app_rename_table, 0001_initial)... OK
  (app_rename_table, 0002_auto_20190414_1500)... ERR
          RENAMING tables

  *** Summary ***
  Valid migrations: 4/8
  Erroneous migrations: 3/8
  Migrations with warnings: 0/8
  Ignored migrations: 1/8
  ```

  The linter analysed all migrations from the Django project.
  It found 3 migrations that are doing backward incompatible operations and 1 that is explicitly ignored.
  The list of incompatibilities that the linter analyses [can be found at docs/incompatibilities.md](./docs/incompatibilities.md).

  More advanced usages of the linter and options [can be found at docs/usage.md](./docs/usage.md).



  One can either integrate the linter in the CI using its `lintmigrations` command, or detect incompatibilities during generation of migrations with
  ```
  $ python manage.py makemigrations --lint

  Migrations for 'app_correct':
    tests/test_project/app_correct/migrations/0003_a_column.py
      - Add field column to a
  Linting for 'app_correct':
  (app_correct, 0003_a_column)... ERR
          NOT NULL constraint on columns

  The migration linter detected that this migration is not backward compatible.
  - If you keep the migration, you will want to fix the issue or ignore the migration.
  - By default, the newly created migration file will be deleted.
  Do you want to keep the migration? [y/N] n
  Deleted tests/test_project/app_correct/migrations/0003_a_column.py
  ```

  The linter found that the newly created migration is not backward compatible and deleted the file after confirmation.
  This behaviour can be the default of the `makemigrations` command through the `MIGRATION_LINTER_OVERRIDE_MAKEMIGRATIONS` Django setting.
  Find out more about the [makemigrations command at docs/makemigrations.md](./docs/makemigrations.md).



  Please find more documentation [in the docs/ folder](./docs/).

  Some implementation details [can be found in the ./docs/internals/ folder](./docs/internals/).



  * [Keeping Django database migrations backward compatible](https://medium.com/3yourmind/keeping-django-database-migrations-backward-compatible-727820260dbb)
  * [Django and its default values](https://medium.com/botify-labs/django-and-its-default-values-c21a13cff9f)



  * [Django News](https://django-news.com/issues/6?m=web#uMmosw7)
  * [wemake-django-template](https://wemake-django-template.readthedocs.io/en/latest/pages/template/linters.html#django-migration-linter)
  * [Testing Django migrations on sobolevn's blog](https://sobolevn.me/2019/10/testing-django-migrations#existing-setup)



  * [django-test-migrations](https://github.com/wemake-services/django-test-migrations) - Test django schema and data migrations, including migrations' order and best practices.



  *django-migration-linter* is released under the [Apache 2.0 License](./LICENSE).


pkgId: 0428219943708d8c20aa907f4ff7c5e96a1cae7cdf637fa89d81230c30c5617e
name: python-django-modelcluster
arch: src
version: 6.0
epoch: 0
release: 1
url: https://github.com/wagtail/django-modelcluster
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c55e4143-78b2-46ba-ad4c-a7f9f70863eb
location_href: 00011577-python-django-modelcluster/python-django-modelcluster-6.0-1.src.rpm
checksum_type: sha256
summary:
  Django extension to allow working with 'clusters' of models as a single unit, independently of the database

description:
  If you had a data model like this:
   class Band(models.Model):
       name = models.CharField(max_length=255)
   class BandMember(models.Model):
       band = models.ForeignKey('Band', related_name='members', on_delete=models.CASCADE)
       name = models.CharField(max_length=255)
  wouldn't it be nice if you could construct bundles of objects like this, independently of the database:
   beatles = Band(name='The Beatles')
   beatles.members = [
       BandMember(name='John Lennon'),
       BandMember(name='Paul McCartney'),
   ]
  Unfortunately, you can't. Objects need to exist in the database for foreign key relations to work:
   IntegrityError: null value in column "band_id" violates not-null constraint
  But what if you could? There are all sorts of scenarios where you might want to work with a 'cluster' of related objects, without necessarily holding them in the database: maybe you want to render a preview of the data the user has just submitted, prior to saving. Maybe you need to construct a tree of things, serialize them and hand them off to some external system. Maybe you have a workflow where your models exist in an incomplete 'draft' state for an extended time, or you need to handle multiple revisions, and you don't want to redesign your database around that requirement.
  **django-modelcluster** extends Django's foreign key relations to make this possible. It introduces a new type of relation, *ParentalKey*, where the related models are stored locally to the 'parent' model until the parent is explicitly saved. Up to that point, the related models can still be accessed through a subset of the QuerySet API:
   from modelcluster.models import ClusterableModel
   from modelcluster.fields import ParentalKey
   class Band(ClusterableModel):
       name = models.CharField(max_length=255)
   class BandMember(models.Model):
       band = ParentalKey('Band', related_name='members', on_delete=models.CASCADE)
       name = models.CharField(max_length=255)
   >>> beatles = Band(name='The Beatles')
   >>> beatles.members = [
   >>> [member.name for member in beatles.members.all()]
   ['John Lennon', 'Paul McCartney']
   >>> beatles.members.add(BandMember(name='George Harrison'))
   >>> beatles.members.count()
   3
   >>> beatles.save()  # only now are the records written to the database
  For more examples, see the unit tests.


pkgId: 1506d4c8344a13a078ab878056e74c82911508bd982fd283fe10e75751514119
name: python-django-money
arch: src
version: 3.0.0
epoch: 0
release: 1
url: https://github.com/django-money/django-money
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7edf992f-b5fe-4f21-a103-19eb511f3df6
location_href: 00011491-python-django-money/python-django-money-3.0.0-1.src.rpm
checksum_type: sha256
summary:
  Adds support for using money and currency fields in django models and forms. Uses py-moneyed as the money implementation.

description:
  A little Django app that uses `py-moneyed <https://github.com/py-moneyed/py-moneyed>`__ to add support for Money
  fields in your models and forms.
  * Django versions supported: 2.2, 3.2, 4.0, 4.1
  * Python versions supported: 3.7, 3.8, 3.9, 3.10
  * PyPy versions supported: PyPy3
  If you need support for older versions of Django and Python, please refer to older releases mentioned in `the release notes <https://django-money.readthedocs.io/en/latest/changes.html>`__.
  Through the dependency `py-moneyed <https://github.com/py-moneyed/py-moneyed>`__, ``django-money`` gets:
  * Support for proper Money value handling (using the standard Money
    design pattern)
  * A currency class and definitions for all currencies in circulation
  * Formatting of most currencies with correct currency sign


pkgId: 97c9b9a886ee0f89654ab39cfc2068ca35bfdc85def9554e186a07aed7c2667a
name: python-django-mptt
arch: src
version: 0.14.0
epoch: 0
release: 1
url: https://github.com/django-mptt/django-mptt/
rpm_license: MIT-License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f943b240-8b67-472c-81a6-77ac9f226c81
location_href: 00003475-python-django-mptt/python-django-mptt-0.14.0-1.src.rpm
checksum_type: sha256
summary:
  Utilities for implementing Modified Preorder Tree Traversal with your Django Models and working with trees of Model instances.


pkgId: 3fe8b87a3e9ecf5adc6d730fd7c299aec993aa96f8b92121bf4cdb15525b0088
name: python-django-multiselectfield
arch: src
version: 0.1.12
epoch: 0
release: 1
summary: Django multiple select field
url: https://github.com/goinnn/django-multiselectfield
rpm_license: LGPL 3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7f8fc1dc-975d-4ac9-bfb4-b19444d2fe7b
location_href: 00011244-python-django-multiselectfield/python-django-multiselectfield-0.1.12-1.src.rpm
checksum_type: sha256
description:
  A new model field and form field. With this you can get a multiple select from a choices. Stores to the database as a CharField of comma-separated values.
  This egg is inspired by this `snippet <http://djangosnippets.org/snippets/1200/>`_.
  Supported Python versions: 2.7, 3.4+
  Supported Django versions: 1.4-2.0+


pkgId: cdac3372cf439b979a91860f0274ca73411f96180f7914e1a329dcdcbf2ad541
name: python-django-nested-admin
arch: src
version: 4.0.2
epoch: 0
release: 1
summary: Django admin classes that allow for nested inlines
url: https://github.com/theatlantic/django-nested-admin
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c62170a6-87df-45b9-bbb9-b81cb7341864
location_href: 00011535-python-django-nested-admin/python-django-nested-admin-4.0.2-1.src.rpm
checksum_type: sha256
description:
  The recommended way to install django-nested-admin is from
  `PyPI <https://pypi.python.org/pypi/django-nested-admin>`_::
          pip install django-nested-admin
  Alternatively, one can install a development copy of django-nested-admin
  from source::
          pip install -e git+git://github.com/theatlantic/django-nested-admin.git#egg=django-nested-admin
  If the source is already checked out, use setuptools to install::
          python setup.py develop


pkgId: ecc4f02bc7a8277347087b947ba91f3245a364e27be10a2a6b91ee1c4f7bea1b
name: python-django-oauth-toolkit
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: OAuth2 Provider for Django
url: https://github.com/jazzband/django-oauth-toolkit
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1c3d200f-c058-4b20-851b-96ad9a698239
location_href: 00010321-python-django-oauth-toolkit/python-django-oauth-toolkit-2.2.0-1.src.rpm
checksum_type: sha256
description:
  *OAuth2 goodies for the Djangonauts!*
  If you are facing one or more of the following:
   * Your Django app exposes a web API you want to protect with OAuth2 authentication,
   * You need to implement an OAuth2 authorization server to provide tokens management for your infrastructure,
  Django OAuth Toolkit can help you providing out of the box all the endpoints, data and logic needed to add OAuth2
  capabilities to your Django projects. Django OAuth Toolkit makes extensive use of the excellent
  `OAuthLib <https://github.com/idan/oauthlib>`_, so that everything is
  `rfc-compliant <http://tools.ietf.org/html/rfc6749>`_.
  Note: If you have issues installing Django 4.0.0, it is because we only support
  Django 4.0.1+ due to a regression in Django 4.0.0. Besides 4.0.0, Django 2.2+ is supported.
  `Explanation <https://github.com/jazzband/django-oauth-toolkit/pull/1046#issuecomment-998015272>`_.


pkgId: 9a2036f01cd106562b06d45a9978a9cdf4d74a4cef037c99cb98bfc6a0e88057
name: python-django-ordered-model
arch: src
version: 3.7.4
epoch: 0
release: 1
summary: Allows Django models to be ordered and provides a simple admin interface for reordering them.
url: http://github.com/django-ordered-model/django-ordered-model
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d40898cf-47d1-4c59-a087-59eec4aa4e2e
location_href: 00012206-python-django-ordered-model/python-django-ordered-model-3.7.4-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://secure.travis-ci.org/bfirsh/django-ordered-model.png?branch=master)](https://travis-ci.org/bfirsh/django-ordered-model)
  [![PyPI version](https://badge.fury.io/py/django-ordered-model.svg)](https://badge.fury.io/py/django-ordered-model)
  [![codecov](https://codecov.io/gh/bfirsh/django-ordered-model/branch/master/graph/badge.svg)](https://codecov.io/gh/bfirsh/django-ordered-model)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/python/black)
  django-ordered-model allows models to be ordered and provides a simple admin
  interface for reordering them.
  Based on https://djangosnippets.org/snippets/998/ and
  https://djangosnippets.org/snippets/259/
  See our [compatability notes](#compatibility-with-django-and-python) for the appropriate version to use with older Django and Python releases.


pkgId: 1fc147f6fdc60893971eb36f6866c1a949e6ad58c248d9dcec930bd10b07174e
name: python-django-otp
arch: src
version: 1.1.6
epoch: 0
release: 1
summary: A pluggable framework for adding two-factor authentication to Django using one-time passwords.
url: https://github.com/django-otp/django-otp
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-42884630-539f-43d6-8895-246f4aed4c9a
location_href: 00010459-python-django-otp/python-django-otp-1.1.6-1.src.rpm
checksum_type: sha256
description:
  This project makes it easy to add support for `one-time passwords
  <http://en.wikipedia.org/wiki/One-time_password>`_ (OTPs) to Django. It can be
  integrated at various levels, depending on how much customization is required.
  It integrates with ``django.contrib.auth``, although it is not a Django
  authentication backend. The primary target is developers wishing to incorporate
  OTPs into their Django projects as a form of `two-factor authentication
  <http://en.wikipedia.org/wiki/Two-factor_authentication>`_.
  Several simple OTP plugins are included and more are available separately. This
  package also includes an implementation of OATH `HOTP
  <http://tools.ietf.org/html/rfc4226>`_ and `TOTP
  <http://tools.ietf.org/html/rfc6238>`_ for convenience, as these are standard
  OTP algorithms used by multiple plugins.
  If you're looking for a higher-level or more opinionated solution, you might be
  interested in `django-two-factor-auth
  <https://github.com/Bouke/django-two-factor-auth>`_.


pkgId: 4e0ee8053aff1794238aa1d6080fa1d980a91601db18f11db77b2134eb8cd7d4
name: python-django-polymorphic
arch: src
version: 3.1.0
epoch: 0
release: 1
summary: Seamless polymorphic inheritance for Django models
url: https://github.com/django-polymorphic/django-polymorphic
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d53c9668-bb93-41d8-8fdd-7f023c140720
location_href: 00010453-python-django-polymorphic/python-django-polymorphic-3.1.0-1.src.rpm
checksum_type: sha256
description:
  Django-polymorphic simplifies using inherited models in Django projects.
  When a query is made at the base model, the inherited model classes are returned.
  When we store models that inherit from a ``Project`` model...
      >>> Project.objects.create(topic="Department Party")
      >>> ArtProject.objects.create(topic="Painting with Tim", artist="T. Turner")
      >>> ResearchProject.objects.create(topic="Swallow Aerodynamics", supervisor="Dr. Winter")
      >>> Project.objects.all()
      [ <Project:         id 1, topic "Department Party">,
        <ArtProject:      id 2, topic "Painting with Tim", artist "T. Turner">,
        <ResearchProject: id 3, topic "Swallow Aerodynamics", supervisor "Dr. Winter"> ]
  Using vanilla Django, we get the base class objects, which is rarely what we wanted:
      >>> Project.objects.all()
      [ <Project: id 1, topic "Department Party">,
        <Project: id 2, topic "Painting with Tim">,
        <Project: id 3, topic "Swallow Aerodynamics"> ]
  This also works when the polymorphic model is accessed via
  ForeignKeys, ManyToManyFields or OneToOneFields.


pkgId: a630959755c5dfa9bbb9d9e01685741bd2f427f3199df45921c51c41388e7b9c
name: python-django-post-office
arch: src
version: 3.6.3
epoch: 0
release: 1
summary: A Django app to monitor and send mail asynchronously, complete with template support.
url: https://github.com/ui/django-post_office
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9fd9f3b8-4032-47be-9a44-02fa704ddc48
location_href: 00003478-python-django-post_office/python-django-post-office-3.6.3-1.src.rpm
checksum_type: sha256
description:
  if Django's caching mechanism is configured, `post_office` will cache
  `EmailTemplate` instances . If for some reason you want to disable
  caching, set `POST_OFFICE_CACHE` to `False` in `settings.py`:
  ```python


  POST_OFFICE_CACHE = False

  CACHES = {
      'post_office': {
          'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
          'LOCATION': '127.0.0.1:11211',
      }
  }
  ```

  `send_many()` is much more performant (generates less database queries)
  when sending a large number of emails. `send_many()` is almost identical
  to `mail.send()`, with the exception that it accepts a list of keyword
  arguments that you'd usually pass into `mail.send()`:
  ```python
  from post_office import mail
  first_email = {
      'sender': 'from@example.com',
      'recipients': ['alice@example.com'],
      'subject': 'Hi!',
      'message': 'Hi Alice!'
  }
  second_email = {
      'sender': 'from@example.com',
      'recipients': ['bob@example.com'],
      'subject': 'Hi!',
      'message': 'Hi Bob!'
  }
  kwargs_list = [first_email, second_email]
  mail.send_many(kwargs_list)
  ```
  Attachments are not supported with `mail.send_many()`.

  To run the test suite:
  ```python
  `which django-admin.py` test post_office --settings=post_office.test_settings --pythonpath=.
  ```
  You can run the full test suite for all supported versions of Django and Python with:
  ```python
  tox
  ```
  or:
  ```python
  python setup.py test
  ```

  If your Django project runs in a Celery enabled configuration, you can use its worker to send out
  queued emails. Compared to the solution with cron (see above), or the solution with uWSGI timers
  (see below) this setup has the big advantage that queued emails are send *immediately* after they
  have been added to the mail queue. The delivery is still performed in a separate and asynchronous
  task, which prevents sending emails during the request/response-cycle.
  If you [configured Celery](https://docs.celeryproject.org/en/latest/userguide/application.html)
  in your project and started the
  [Celery worker](https://docs.celeryproject.org/en/latest/userguide/workers.html),
  you should see something such as:


pkgId: 77c3fb898cadd380914fd04d0b2fa44cb5a968720ad307db144ebd1badcfd30a
name: python-django-prettyjson
arch: src
version: 0.4.1
epoch: 0
release: 1
summary: Enables pretty JSON viewer in Django forms, admin, or templates
url: https://github.com/kevinmickey/django-prettyjson
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-81efeb24-b049-4fa2-add8-21c30e46f7f9
location_href: 00011975-python-django-prettyjson/python-django-prettyjson-0.4.1-1.src.rpm
checksum_type: sha256
description:
  0.1.0 (2016-05-28)
  ++++++++++++++++++
  * First release.
  0.2.0 (2016-05-29)
  ++++++++++++++++++
  * Switched to using standardjson for encoding objects
  * Added setup option for those with jquery already loaded
  0.2.1 (2016-07-01)
  ++++++++++++++++++
  * Fixed manifest
  0.2.2 (2016-12-07)
  ++++++++++++++++++
  * Added dependencies to setup.py
  0.3.0 (2017-05-23)
  ++++++++++++++++++
  * Added "initial" option to show raw or parsed initial
  * Requires six
  0.3.1 (2018-04-01)
  ++++++++++++++++++
  * Allows CSS control of parsed widget
  0.3.2 (2018-04-09)
  ++++++++++++++++++
  * Fixes widget media order
  0.3.3 (2018-04-13)
  ++++++++++++++++++
  * Fixes string passed as parameter
  0.4.0 (2018-04-30)
  ++++++++++++++++++
  * Allows attrs in template tag
  * Fix JS for initial parsed with multiple widgets
  * Change parsed CSS height to max-height
  0.4.1 (2018-08-07)
  ++++++++++++++++++
  * Fix widget for Django 2.1


pkgId: 14325f8dd5ad158532db59527eaa81640d72f3aa321b34fd03e82005c7e46d85
name: python-django-prometheus
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: Django middlewares to monitor your application with Prometheus.io.
url: http://github.com/korfuri/django-prometheus
rpm_license: Apache
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fb4905e3-dd5e-4245-b4c8-5c93cab821f3
location_href: 00003479-python-django-prometheus/python-django-prometheus-2.2.0-1.src.rpm
checksum_type: sha256
description:
  Export Django monitoring metrics for Prometheus.io

  [![Join the chat at https://gitter.im/django-prometheus/community](https://badges.gitter.im/django-prometheus/community.svg)](https://gitter.im/django-prometheus/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)

  [![PyPI version](https://badge.fury.io/py/django-prometheus.svg)](http://badge.fury.io/py/django-prometheus)
  [![Build Status](https://github.com/korfuri/django-prometheus/actions/workflows/ci.yml/badge.svg)](https://github.com/korfuri/django-prometheus/actions/workflows/ci.yml)
  [![Coverage Status](https://coveralls.io/repos/github/korfuri/django-prometheus/badge.svg?branch=master)](https://coveralls.io/github/korfuri/django-prometheus?branch=master)
  [![PyPi page link -- Python versions](https://img.shields.io/pypi/pyversions/django-prometheus.svg)](https://pypi.python.org/pypi/django-prometheus)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)



  This library provides Prometheus metrics for Django related operations:

  * Requests & Responses
  * Database access done via [Django ORM](https://docs.djangoproject.com/en/3.0/topics/db/)
  * Cache access done via [Django Cache framework](https://docs.djangoproject.com/en/3.0/topics/cache/)





  * Django >= 2.2



  Install with:

  ```shell
  pip install django-prometheus
  ```

  Or, if you're using a development version cloned from this repository:

  ```shell
  python path-to-where-you-cloned-django-prometheus/setup.py install
  ```

  This will install [prometheus_client](https://github.com/prometheus/client_python) as a dependency.



  In your settings.py:

  ```python
  INSTALLED_APPS = [
     ...
     'django_prometheus',
     ...
  ]

  MIDDLEWARE = [
      'django_prometheus.middleware.PrometheusBeforeMiddleware',
      
      
      
      'django_prometheus.middleware.PrometheusAfterMiddleware',
  ]
  ```

  In your urls.py:

  ```python
  urlpatterns = [
      ...
      path('', include('django_prometheus.urls')),
  ]
  ```



  Prometheus uses Histogram based grouping for monitoring latencies. The default
  buckets are here: https://github.com/prometheus/client_python/blob/master/prometheus_client/core.py

  You can define custom buckets for latency, adding more buckets decreases performance but
  increases accuracy: https://prometheus.io/docs/practices/histograms/

  ```python
  PROMETHEUS_LATENCY_BUCKETS = (.1, .2, .5, .6, .8, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.5, 9.0, 12.0, 15.0, 20.0, 30.0, float("inf"))
  ```



  SQLite, MySQL, and PostgreSQL databases can be monitored. Just
  replace the `ENGINE` property of your database, replacing
  `django.db.backends` with `django_prometheus.db.backends`.

  ```python
  DATABASES = {
      'default': {
          'ENGINE': 'django_prometheus.db.backends.sqlite3',
          'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
      },
  }
  ```



  Filebased, memcached, redis caches can be monitored. Just replace
  the cache backend to use the one provided by django_prometheus
  `django.core.cache.backends` with `django_prometheus.cache.backends`.

  ```python
  CACHES = {
      'default': {
          'BACKEND': 'django_prometheus.cache.backends.filebased.FileBasedCache',
          'LOCATION': '/var/tmp/django_cache',
      }
  }
  ```



  You may want to monitor the creation/deletion/update rate for your
  model. This can be done by adding a mixin to them. This is safe to do
  on existing models (it does not require a migration).

  If your model is:

  ```python
  class Dog(models.Model):
      name = models.CharField(max_length=100, unique=True)
      breed = models.CharField(max_length=100, blank=True, null=True)
      age = models.PositiveIntegerField(blank=True, null=True)
  ```

  Just add the `ExportModelOperationsMixin` as such:

  ```python
  from django_prometheus.models import ExportModelOperationsMixin

  class Dog(ExportModelOperationsMixin('dog'), models.Model):
      name = models.CharField(max_length=100, unique=True)
      breed = models.CharField(max_length=100, blank=True, null=True)
      age = models.PositiveIntegerField(blank=True, null=True)
  ```

  This will export 3 metrics, `django_model_inserts_total{model="dog"}`,
  `django_model_updates_total{model="dog"}` and
  `django_model_deletes_total{model="dog"}`.

  Note that the exported metrics are counters of creations,
  modifications and deletions done in the current process. They are not
  gauges of the number of objects in the model.

  Starting with Django 1.7, migrations are also monitored. Two gauges
  are exported, `django_migrations_applied_by_connection` and
  `django_migrations_unapplied_by_connection`. You may want to alert if
  there are unapplied migrations.

  If you want to disable the Django migration metrics, set the
  `PROMETHEUS_EXPORT_MIGRATIONS` setting to False.



  Prometheus is quite easy to set up. An example prometheus.conf to
  scrape `127.0.0.1:8001` can be found in `examples/prometheus`.

  Here's an example of a PromDash displaying some of the metrics
  collected by django-prometheus:

  ![Example dashboard](https://raw.githubusercontent.com/korfuri/django-prometheus/master/examples/django-promdash.png)



  You can add application-level metrics in your code by using
  [prometheus_client](https://github.com/prometheus/client_python)
  directly. The exporter is global and will pick up your metrics.

  To add metrics to the Django internals, the easiest way is to extend
  django-prometheus' classes. Please consider contributing your metrics,
  pull requests are welcome. Make sure to read the Prometheus best
  practices on
  [instrumentation](http://prometheus.io/docs/practices/instrumentation/)
  and [naming](http://prometheus.io/docs/practices/naming/).



  If you wish to use Django Prometheus but are not able to change
  the code base, it's possible to have all the default metrics by
  modifying only the settings.

  First step is to inject prometheus' middlewares and to add
  django_prometheus in INSTALLED_APPS

  ```python
  MIDDLEWARE = \
      ['django_prometheus.middleware.PrometheusBeforeMiddleware'] + \
      MIDDLEWARE + \
      ['django_prometheus.middleware.PrometheusAfterMiddleware']

  INSTALLED_APPS += ['django_prometheus']
  ```

  Second step is to create the /metrics end point, for that we need
  another file (called urls_prometheus_wrapper.py in this example) that
  will wraps the apps URLs and add one on top:

  ```python
  from django.urls import include, path


  urlpatterns = []

  urlpatterns.append(path('prometheus/', include('django_prometheus.urls')))
  urlpatterns.append(path('', include('myapp.urls')))
  ```

  This file will add a "/prometheus/metrics" end point to the URLs of django
  that will export the metrics (replace myapp by your project name).

  Then we inject the wrapper in settings:

  ```python
  ROOT_URLCONF = "graphite.urls_prometheus_wrapper"
  ```



  You can add application specific labels to metrics reported by the django-prometheus middleware.
  This involves extending the classes defined in middleware.py.

  * Extend the Metrics class and override the `register_metric` method to add the application specific labels.
  * Extend middleware classes, set the metrics_cls class attribute to the the extended metric class and override the label_metric method to attach custom metrics.

  See implementation example in [the test app](django_prometheus/tests/end2end/testapp/test_middleware_custom_labels.py#L19-L46)


pkgId: 8b4f74611b789bc398a8818ffa1e9efd02018c804fb328ac536912930b3e9b1e
name: python-django-push-notifications
arch: src
version: 3.0.0
epoch: 0
release: 1
url: https://github.com/jazzband/django-push-notifications
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-695beb9c-410f-42a9-8d49-e7840168aefc
location_href: 00013429-python-django-push-notifications/python-django-push-notifications-3.0.0-1.src.rpm
checksum_type: sha256
summary:
  Send push notifications to mobile devices through GCM, APNS or WNS and to WebPush (Chrome, Firefox and Opera) in Django


pkgId: 69d1056aea67f7ca632dc3a7ab5f75b9b2bb43d3c8fa11ffc356f89e42a3d33e
name: python-django-pyscss
arch: src
version: 2.0.2
epoch: 0
release: 1
summary: Makes it easier to use PySCSS in Django.
url: https://github.com/fusionbox/django-pyscss
rpm_license: UNKNOWN
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b694dd5e-1ed1-468c-b3f3-ec10aa145f82
location_href: 00003480-python-django-pyscss/python-django-pyscss-2.0.2-1.src.rpm
checksum_type: sha256
description:
  A collection of tools for making it easier to use pyScss within Django.
      This version only supports pyScss 1.3.4 and greater. For pyScss 1.2 support,
      you can use the 1.x series of django-pyscss.


pkgId: 251f59e124f293a253421d5596a017a6bbeda76d52d5d1333c8012e45c83e703
name: python-django-pytest
arch: src
version: 0.2.0
epoch: 0
release: 1
summary: django test runner to use py.test tests
url: http://github.com/buchuki/django-pytest
rpm_license: LICENSE.txt
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-82003ea4-e6b8-4338-a77e-574897377ecb
location_href: 00003481-python-django-pytest/python-django-pytest-0.2.0-1.src.rpm
checksum_type: sha256
description:
  This project allows you to use py.test as a django test runner, instead of the
  default test runner.
  To use it, add it to your python path and add `django_pytest` to your installed
  apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting.
  If you're using Django 1.3 or newer set
  `TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print
  deprecation warnings each time you run your tests.
  Also create a `conftest.py` in your project directory and include:
  	from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client
  You can also use:
  	from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups
  to import a user or some groups with users in them
  Now anywhere in your project, you can create files called
  `test_<something>.py`.  These are standard py.test test files. Use the funcarg
  `client` in every test to both instantiate a test database that is cleared
  after each test and to provide you with a django test client object identical
  to the one used in django's test system. For example:
  	def test_filter(client):
      	response = client.get('/browse/', {'filter': '1'})
      	assert response.status_code == 200
  Use `./manage.py test` to run the py.test test runs (ie: it replaces the
  standard django test runner). You can pass py.test options to the command
  and they will be forwarded to py.test. (Technically, I haven't got it passing
  all options, just the most common ones I use)
  The management command has been set up so that syncdb will use the django core
  syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This
  prevents migrations from running when running unit tests. This speeds up test
  setup significantly, but it means your test db may not be identical to
  production, if you have faulty migrations.
  py.test automatically picks up any subclasses of `unittest.TestCase`, provided
  they are in a module named `test_<something>.py`. Thus, all your existing django
  unittests should work seemlessly with py.test, although you may have to rename
  your test files if they do not conform to this convention. You can also write
  custom py.test test collection hooks to pick up test modules that are named in
  a different directory structure.
  This project differs from <http://github.com/bfirsh/pytest_django> in that it
  provides a django test runner that calls py.test, rather than creating a
  py.test plugin to test django projects. I believe there is overlapping
  functionality from the two projects, and also that they can be integrated into
  a single project, but I have not looked at the feasibility of this yet.


pkgId: b1a2cdbc467bf0023c2da0277575591301c9b935938e2eae01b3782359d81c07
name: python-django-q
arch: src
version: 1.3.9
epoch: 0
release: 1
summary: A multiprocessing distributed task queue for Django
url: https://django-q.readthedocs.org
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e8b6f062-0f63-40e2-ba4b-68f5b4db4ba5
location_href: 00012475-python-django-q/python-django-q-1.3.9-1.src.rpm
checksum_type: sha256
description:
  |image0| |image1| |docs| |image2|
  Features
  ~~~~~~~~
  -  Multiprocessing worker pool
  -  Asynchronous tasks
  -  Scheduled, cron and repeated tasks
  -  Signed and compressed packages
  -  Failure and success database or cache
  -  Result hooks, groups and chains
  -  Django Admin integration
  -  PaaS compatible with multiple instances
  -  Multi cluster monitor
  -  Redis, Disque, IronMQ, SQS, MongoDB or ORM
  -  Rollbar and Sentry support
  Requirements
  ~~~~~~~~~~~~
  -  `Django <https://www.djangoproject.com>`__ > = 2.2
  -  `Django-picklefield <https://github.com/gintas/django-picklefield>`__
  -  `Arrow <https://github.com/crsmithdev/arrow>`__
  -  `Blessed <https://github.com/jquast/blessed>`__
  Tested with: Python 3.7, 3.8, 3.9 Django 2.2.X and 3.2.X
  Brokers
  ~~~~~~~
  - `Redis <https://django-q.readthedocs.org/en/latest/brokers.html#redis>`__
  - `Disque <https://django-q.readthedocs.org/en/latest/brokers.html#disque>`__
  - `IronMQ <https://django-q.readthedocs.org/en/latest/brokers.html#ironmq>`__
  - `Amazon SQS <https://django-q.readthedocs.org/en/latest/brokers.html#amazon-sqs>`__
  - `MongoDB <https://django-q.readthedocs.org/en/latest/brokers.html#mongodb>`__
  - `Django ORM <https://django-q.readthedocs.org/en/latest/brokers.html#django-orm>`__
  Installation
  ~~~~~~~~~~~~
  -  Install the latest version with pip::
      $ pip install django-q
  -  Add `django_q` to your `INSTALLED_APPS` in your projects `settings.py`::
         INSTALLED_APPS = (
             
             'django_q',
         )
  -  Run Django migrations to create the database tables::
      $ python manage.py migrate
  -  Choose a message `broker <https://django-q.readthedocs.org/en/latest/brokers.html>`__ , configure and install the appropriate client library.
  Read the full documentation at `https://django-q.readthedocs.org <https://django-q.readthedocs.org>`__
  Configuration
  ~~~~~~~~~~~~~
  All configuration settings are optional. e.g:
      
      Q_CLUSTER = {
          'name': 'myproject',
          'workers': 8,
          'recycle': 500,
          'timeout': 60,
          'compress': True,
          'cpu_affinity': 1,
          'save_limit': 250,
          'queue_limit': 500,
          'label': 'Django Q',
          'redis': {
              'host': '127.0.0.1',
              'port': 6379,
              'db': 0, }
      }
  For full configuration options, see the `configuration documentation <https://django-q.readthedocs.org/en/latest/configure.html>`__.
  Management Commands
  ~~~~~~~~~~~~~~~~~~~
  Start a cluster with::
      $ python manage.py qcluster
  Monitor your clusters with::
      $ python manage.py qmonitor
  Monitor your clusters' memory usage with::
      $ python manage.py qmemory
  Check overall statistics with::
      $ python manage.py qinfo
  Creating Tasks
  ~~~~~~~~~~~~~~
  Use `async_task` from your code to quickly offload tasks:
      from django_q.tasks import async_task, result
      
      async_task('math.copysign', 2, -2)
      
      import math.copysign
      task_id = async_task(copysign, 2, -2)
      
      task_result = result(task_id)
      
      
      task_result = result(task_id, 200)
      
      async_task('math.modf', 2.5, hook='hooks.print_result')
      
      def print_result(task):
          print(task.result)
  For more info see `Tasks <https://django-q.readthedocs.org/en/latest/tasks.html>`__
  Schedule
  ~~~~~~~~
  Schedules are regular Django models. You can manage them through the
  Admin page or directly from your code:
      
      from django_q.tasks import schedule
      schedule('math.copysign',
               2, -2,
               hook='hooks.print_result',
               schedule_type=Schedule.DAILY)
      
      from django_q.models import Schedule
      Schedule.objects.create(func='math.copysign',
                              hook='hooks.print_result',
                              args='2,-2',
                              schedule_type=Schedule.DAILY
                              )
      
      
      import arrow
      schedule('math.hypot',
               3, 4,
               schedule_type=Schedule.MINUTES,
               minutes=5,
               repeats=24,
               next_run=arrow.utcnow().replace(hour=18, minute=0))
      
      schedule('math.hypot',
               3, 4,
               schedule_type=Schedule.CRON,
               cron = '0 22 * * 1-5')
  For more info check the `Schedules <https://django-q.readthedocs.org/en/latest/schedules.html>`__ documentation.
  Testing
  ~~~~~~~
  To run the tests you will need the following in addition to install requirements:
  * `py.test <http://pytest.org/latest/>`__
  * `pytest-django <https://github.com/pytest-dev/pytest-django>`__
  * Disque from https://github.com/antirez/disque.git
  * Redis
  * MongoDB
  Or you can use the included Docker Compose file.
  The following commands can be used to run the tests:
      
      python -m venv venv
      
      venv/bin/pip install -r requirements.txt
      
      venv/bin/pip install pytest pytest-django
      
      venv/bin/python setup.py develop
      
      docker-compose -f test-services-docker-compose.yaml up -d
      
      venv/bin/pytest
      
      docker-compose -f test-services-docker-compose.yaml down
  Locale
  ~~~~~~
  Currently available in English, German and French.
  Translation pull requests are always welcome.
  Todo
  ~~~~
  -  Better tests and coverage
  -  Less dependencies?
  Acknowledgements
  ~~~~~~~~~~~~~~~~
  -  Django Q was inspired by working with
     `Django-RQ <https://github.com/ui/django-rq>`__ and
     `RQ <https://github.com/ui/django-rq>`__
  -  Human readable hashes by
     `HumanHash <https://github.com/zacharyvoase/humanhash>`__
  -  Redditors feedback at `r/django <https://www.reddit.com/r/django/>`__
  -  JetBrains for their `Open Source Support Program <https://www.jetbrains.com/community/opensource>`__


pkgId: 628456244f65bf4dcd54586e3fd9a84efc1f8fe20af8affc21a82f62071897d0
name: python-django-recaptcha
arch: src
version: 3.0.0
epoch: 0
release: 1
summary: Django recaptcha form field/widget app.
url: https://github.com/torchbox/django-recaptcha
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-129f3a47-a798-4a32-b200-b032a0e662c0
location_href: 00011864-python-django-recaptcha/python-django-recaptcha-3.0.0-1.src.rpm
checksum_type: sha256
description:
  **Django reCAPTCHA form field/widget integration app.**
     django-recaptcha supports Google reCAPTCHA V2 - Checkbox (Default), Google reCAPTCHA V2 - Invisible and Google reCAPTCHA V3 please look at the widgets section for more information.
     Django reCAPTCHA uses a modified version of the `Python reCAPTCHA client <http://pypi.python.org/pypi/recaptcha-client>`_ which is included in the package as ``client.py``.


pkgId: 49a696baea7c05fe57202f5061c3f9c863d70ceec11ea30265602ff74e6dbd55
name: python-django-redis-sessions
arch: src
version: 0.6.2
epoch: 0
release: 1
summary: Redis Session Backend For Django
url: http://github.com/martinrusev/django-redis-sessions
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b4a055aa-8979-4567-aea5-3581c784dcf5
location_href: 00012149-python-django-redis-sessions/python-django-redis-sessions-0.6.2-1.src.rpm
checksum_type: sha256
description:
  Redis database backend for your sessions
  |Build Status|
  -  `Installation`_
  -  `Available Settings`_
  -  `Changelog`_


pkgId: 331195260cde1d05f711280a320e7f860e28a7713c3da4e6ac1a9411ddbcfacf
name: python-django-registration
arch: src
version: 3.3
epoch: 0
release: 1
summary: An extensible user-registration application for Django
url: https://github.com/ubernostrum/django-registration/
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-87438904-7aa1-4f24-9e98-571e7707ad6a
location_href: 00003483-python-django-registration/python-django-registration-3.3-1.src.rpm
checksum_type: sha256
description:
  .. -*-restructuredtext-*-

  .. image:: https://github.com/ubernostrum/django-registration/workflows/CI/badge.svg
     :alt: CI status image
     :target: https://github.com/ubernostrum/django-registration/actions?query=workflow%3ACI

  This is a user-registration application for `Django
  <https://www.djangoproject.com/>`_. There are two registration
  workflows (one-step, and two-step with activation) built in, and it's
  designed to be extensible and support building additional workflows.

  To get started, check out `the documentation
  <https://django-registration.readthedocs.io/>`_.


pkgId: 2cce6ab056f0d0cf030f987e3a750838def34a23eeb27ce7f0be3644ecc2693e
name: python-django-request-logging
arch: src
version: 0.7.5
epoch: 0
release: 1
summary: Django middleware that logs http request body.
url: https://github.com/Rhumbix/django-request-logging.git
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-376f77f3-f704-4212-8860-3b8473abfbff
location_href: 00012570-python-django-request-logging/python-django-request-logging-0.7.5-1.src.rpm
checksum_type: sha256
description:
  Plug django-request-logging into your Django project and you will have intuitive and color coded request/response payload logging, for both web requests and API requests. Supports Django 1.8+.

  ```bash
  $ pip install django-request-logging
  ```
  Then add ```request_logging.middleware.LoggingMiddleware``` to your ```MIDDLEWARE```.
  For example:
  ```python
  MIDDLEWARE = (
      'request_logging.middleware.LoggingMiddleware',
  )
  ```
  And configure logging in your app:
  ```python
  LOGGING = {
      'version': 1,
      'disable_existing_loggers': False,
      'handlers': {
          'console': {
              'class': 'logging.StreamHandler',
          },
      },
      'loggers': {
          'django.request': {
              'handlers': ['console'],
              'level': 'DEBUG',  # change debug level as appropiate
              'propagate': False,
          },
      },
  }
  ```

  Most of the times you don't have to care about these details. But in case you need to dig deep:
  * All logs are configured using logger name "django.request".
  * If HTTP status code is between 400 - 599, URIs are logged at ERROR level, otherwise they are logged at INFO level.
  * If HTTP status code is between 400 - 599, data are logged at ERROR level, otherwise they are logged at DEBUG level.
  See `REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL` setting to override this.
  A `no_logging` decorator is included for views with sensitive data. This decorator allows control over logging behaviour of single views via the following parameters:
  ```
  * value
      * False: the view does NOT log any activity at all (overrules settings of log_headers, log_body, log_response and automatically sets them to False).
      * True: the view logs incoming requests (potentially log headers, body and response, depending on their specific settings)
      * None: NO_LOGGING_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_NO_LOGGING_DEFAULT_VALUE)
  * msg
      * Reason for deactivation of logging gets logged instead of request itself (only if silent=True and value=False)
      * NO_LOGGING_MSG is used by default
  * log_headers
      * False: request headers will not get logged
      * True: request headers will get logged (if value is True)
      * None: LOG_HEADERS_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_LOG_HEADERS_DEFAULT_VALUE)
  * no_header_logging_msg
      * Reason for deactivation of header logging gets logged instead of headers (only if silent=True and log_headers=False)
      * NO_HEADER_LOGGING_MSG is used by default
  * log_body
      * False: request body will not get logged
      * True: request headers will get logged (if value is True)
      * None: LOG_BODY_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_LOG_BODY_DEFAULT_VALUE)
  * no_body_logging_msg
      * Reason for deactivation of body logging gets logged instead of body (only if silent=True and log_body=False)
      * NO_BODY_LOGGING_MSG is used by default
  * log_response
      * False: response will not get logged
      * True: response will get logged (if value is True)
      * None: LOG_RESPONSE_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_LOG_RESPONSE_DEFAULT_VALUE)
  * no_response_logging_msg
      * Reason for deactivation of body logging gets logged instead of body (only if silent=True and log_body=False)
      * NO_RESPONSE_LOGGING_MSG is used by default
  * silent
      * True: deactivate logging of alternative messages case parts of the logging are deactivated (request/header/body/response)
      * False: alternative messages for deactivated parts of logging (request/header/body/response) are logged instead
  ```
  By default, value of Http headers `HTTP_AUTHORIZATION` and `HTTP_PROXY_AUTHORIZATION` are replaced wih `*****`. You can use `REQUEST_LOGGING_SENSITIVE_HEADERS` setting to override this default behaviour with your list of sensitive headers.

  You can customized some behaves of django-request-logging by following settings in Django `settings.py`.

  By default, data will log in DEBUG level, you can change to other valid level (Ex. logging.INFO) if need.

  It's enabled by default. If you want to log into log file instead of console, you may want to remove ANSI color. You can set `REQUEST_LOGGING_ENABLE_COLORIZE=False` to disable colorize.

  This legacy setting will still available, but you should't use this setting anymore. You should use `REQUEST_LOGGING_ENABLE_COLORIZE` instead.
  We keep this settings for backward compatibility.

  By default, max length of a request body and a response content is cut to 50000 characters.

  By default, HTTP status codes between 400 - 499 are logged at ERROR level.  You can set `REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL=logging.WARNING` (etc) to override this.
  If you set `REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL=logging.INFO` they will be logged the same as normal requests.

  The value of the headers defined in this settings will be replaced with `'*****'` to hide the sensitive information while logging. By default it is set as `REQUEST_LOGGING_SENSITIVE_HEADERS = ["HTTP_AUTHORIZATION", "HTTP_PROXY_AUTHORIZATION"]`

  Name of the logger that is used to log django.request occurrances with the new LoggingMiddleware. Defaults to "django.request".

  Global default to activate/deactivate logging of all views. Can be overruled for each individual view by using the @no_logging decator's "value" parameter.

  Global default to activate/deactivate logging of request headers for all views. Can be overruled for each individual view by using the @no_logging decator's "log_headers" parameter.

  Global default to activate/deactivate logging of request bodys for all views. Can be overruled for each individual view by using the @no_logging decator's "log_body" parameter.

  Global default to activate/deactivate logging of responses for all views. Can be overruled for each individual view by using the @no_logging decator's "log_response" parameter.


  Use `pyenv` to maintain a set of virtualenvs for 2.7 and a couple versions of Python 3.
  Make sure the `requirements-dev.txt` installs for all of them, at least until we give up on 2.7.
  At that point, update this README to let users know the last version they can use with 2.7.

  - `pip install twine pypandoc pbr wheel`
  - If `pypandoc` complains that `pandoc` isn't installed, you can add that via `brew` if you have Homebrew installed
  - You will need a `.pypirc` file in your user root folder that looks like this:
  ```
      index-servers=
          testpypi
          pypi
      [testpypi]
      username = rhumbix
      password = password for dev@rhumbix.com at Pypi
      [pypi]
      username = rhumbix
      password = password for dev@rhumbix.com at Pypi
  ```

  - Bump the version value in `request_logging/__init__.py`
  - Run `python setup.py publish`
  - Manually tag per the instructions in the output of that command
  - TODO: add automagic `git tag` logic to the publish process
  - TODO: setup 2FA at Pypi


pkgId: 9e714540913570222922bfb275ee58a4160ddc37554e73664405c91640da3e40
name: python-django-rest-knox
arch: src
version: 4.2.0
epoch: 0
release: 1
summary: Authentication for django rest framework
url: https://github.com/James1345/django-rest-knox
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-07bc300a-2add-48bf-82d1-7bcb35958a05
location_href: 00012264-python-django-rest-knox/python-django-rest-knox-4.2.0-1.src.rpm
checksum_type: sha256
description:
  [![image](https://github.com/James1345/django-rest-knox/workflows/Test/badge.svg?branch=develop)](https://github.com/James1345/django-rest-knox/actions)
  Authentication Module for django rest auth
  Knox provides easy to use authentication for [Django REST
  Framework](https://www.django-rest-framework.org/) The aim is to allow
  for common patterns in applications that are REST based, with little
  extra effort; and to ensure that connections remain secure.
  Knox authentication is token based, similar to the `TokenAuthentication`
  built in to DRF. However, it overcomes some problems present in the
  default implementation:
  -   DRF tokens are limited to one per user. This does not facilitate
      securely signing in from multiple devices, as the token is shared.
      It also requires *all* devices to be logged out if a server-side
      logout is required (i.e. the token is deleted).
      Knox provides one token per call to the login view - allowing each
      client to have its own token which is deleted on the server side
      when the client logs out.
      Knox also provides an option for a logged in client to remove *all*
      tokens that the server has - forcing all clients to re-authenticate.
  -   DRF tokens are stored unencrypted in the database. This would allow
      an attacker unrestricted access to an account with a token if the
      database were compromised.
      Knox tokens are only stored in a secure hash form (like a password). Even if the
      database were somehow stolen, an attacker would not be able to log
      in with the stolen credentials.
  -   DRF tokens track their creation time, but have no inbuilt mechanism
      for tokens expiring. Knox tokens can have an expiry configured in
      the app settings (default is 10 hours.)
  More information can be found in the
  [Documentation](https://james1345.github.io/django-rest-knox/)

  If you need to debug a test locally and if you have [docker](https://www.docker.com/) installed:
  simply run the ``./docker-run-tests.sh`` script and it will run the test suite in every Python /
  Django versions.
  You could also simply run regular ``tox`` in the root folder as well, but that would make testing the matrix of
  Python / Django versions a bit more tricky.

  Our documentation is generated by [Mkdocs](https://www.mkdocs.org).
  You can refer to their documentation on how to install it locally.
  Another option is to use `mkdocs.sh` in this repository.
  It will run mkdocs in a [docker](https://www.docker.com/) container.
  Running the script without any params triggers the `serve` command.
  The server is exposed on localhost on port 8000.
  To configure the port the `serve` command will be exposing the server to, you
  can use the following env var:
  ```
  MKDOCS_DEV_PORT="8080"
  ```
  You can also pass any `mkdocs` command like this:
  ```
  ./mkdocs build
  ./mkdocs --help
  ```
  Check the [Mkdocs documentation](https://www.mkdocs.org/) for more.


pkgId: 81ecfffb34a1f4b23c663b06ae7471c0f63de9baf2ff5d06ecb604119e97adf6
name: python-django-rest-passwordreset
arch: src
version: 1.3.0
epoch: 0
release: 1
summary: An extension of django rest framework, providing a configurable password reset strategy
url: https://github.com/anexia-it/django-rest-passwordreset
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-10895aa7-fd61-4bb3-b07f-c417772c098e
location_href: 00012609-python-django-rest-passwordreset/python-django-rest-passwordreset-1.3.0-1.src.rpm
checksum_type: sha256
description:
  0.9.7 | 1.8, 1.11, 2.0, 2.1 | 3.6 - 3.9 | 2.7
  1.0 | 1.11, 2.0, 2.2 | 3.6 - 3.9 | 2.7
  1.1 | 1.11, 2.2 | 3.6 - 3.9 | 2.7
  1.2 | 2.2, 3.0, 3.1 | 3.10, 3.11 | 3.5 - 3.8
  1.3 | 3.2, 4.0, 4.1 | 3.12, 3.13 | 3.7 - 3.10

  This package supports the [DRF auto-generated documentation](https://www.django-rest-framework.org/topics/documenting-your-api/) (via `coreapi`) as well as the [DRF browsable API](https://www.django-rest-framework.org/topics/browsable-api/).
  To add the endpoints to the browsable API, you can use a helper function in your `urls.py` file:
  ```python
  from rest_framework.routers import DefaultRouter
  from django_rest_passwordreset.urls import add_reset_password_urls_to_router
  router = DefaultRouter()
  add_reset_password_urls_to_router(router, base_path='api/auth/passwordreset')
  ```
  Alternatively you can import the ViewSets manually and customize the routes for your setup:
  ```python
  from rest_framework.routers import DefaultRouter
  from django_rest_passwordreset.views import ResetPasswordValidateTokenViewSet, ResetPasswordConfirmViewSet, \
      ResetPasswordRequestTokenViewSet
  router = DefaultRouter()
  router.register(
      r'api/auth/passwordreset/validate_token',
      ResetPasswordValidateTokenViewSet,
      basename='reset-password-validate'
  )
  router.register(
      r'api/auth/passwordreset/confirm',
      ResetPasswordConfirmViewSet,
      basename='reset-password-confirm'
  )
  router.register(
      r'api/auth/passwordreset/',
      ResetPasswordRequestTokenViewSet,
      basename='reset-password-request'
  )
  ```
  ![drf_browsable_email_validation](docs/browsable_api_email_validation.png "Browsable API E-Mail Validation")
  ![drf_browsable_password_validation](docs/browsable_api_password_validation.png "Browsable API E-Mail Validation")
  ![coreapi_docs](docs/coreapi_docs.png "Core API Docs")


  Django 2.1 introduced a breaking change for migrations (see [Django Issue #29790](https://code.djangoproject.com/ticket/29790)). We therefore had to rewrite the migration [0002_pk_migration.py](django_rest_passwordreset/migrations/0002_pk_migration.py) such that it covers Django versions before (`<`) 2.1 and later (`>=`) 2.1.
  Some information is written down in Issue #8.

  You need to make sure that the code with `@receiver(reset_password_token_created)` is executed by the python interpreter. To ensure this, you have two options:
  1. Put the code at a place that is automatically loaded by Django (e.g., models.py, views.py), or
  2. Import the file that contains the signal within your app.py `ready` function:
    *some_app/signals.py*
    ```python
    from django.core.mail import EmailMultiAlternatives
    from django.dispatch import receiver
    from django.template.loader import render_to_string
    from django.urls import reverse
    from django_rest_passwordreset.signals import reset_password_token_created
    @receiver(reset_password_token_created)
    def password_reset_token_created(sender, instance, reset_password_token, *args, **kwargs):
        
    ```
    *some_app/app.py*
    ```python
    from django.apps import AppConfig
    class SomeAppConfig(AppConfig):
        name = 'your_django_project.some_app'
        verbose_name = 'Some App'
        def ready(self):
            import your_django_project.some_app.signals  # noqa
    ```
    *some_app/__init__.py*
    ```python
    default_app_config = 'your_django_project.some_app.SomeAppConfig'
    ```

  Apparently, the following piece of code in the Django Model prevents MongodB from working:
  ```python
   id = models.AutoField(
       primary_key=True
   )
  ```
  See issue #49 for details.

  This library tries to follow the unix philosophy of "do one thing and do it well" (which is providing a basic password reset endpoint for Django Rest Framework). Contributions are welcome in the form of pull requests and issues! If you create a pull request, please make sure that you are not introducing breaking changes.

  See folder [tests/](tests/). Basically, all endpoints are covered with multiple
  unit tests.
  Use this code snippet to run tests:
  ```bash
  python setup.py install
  cd tests
  python manage.py test
  ```

  To release this package on pypi, the following steps are used:
  ```bash
  rm -rf dist/ build/
  python setup.py sdist
  twine upload dist/*
  ```


pkgId: c8b262c1a01b46c212caa20b5c9d10ae09eb751138e6fa623cdfc31b52e1852d
name: python-django-rest-swagger
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: Swagger UI for Django REST Framework 3.5+
url: https://github.com/marcgibbons/django-rest-swagger
rpm_license: FreeBSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6e1b43b8-0fbb-4d81-9c28-d0f46c513444
location_href: 00010386-python-django-rest-swagger/python-django-rest-swagger-2.2.0-1.src.rpm
checksum_type: sha256
description:
  Django REST Swagger

  An API documentation generator for Swagger UI and Django REST Framework.

  Installation
  From pip:

  pip install django-rest-swagger

  Project @ https://github.com/marcgibbons/django-rest-swagger
  Docs @ https://django-rest-swagger.readthedocs.io/


pkgId: 6126a12425629e244a2a085c92d6a7f6e94ec8066fd443a1189bbb5deb242bbb
name: python-django-rules
arch: src
version: 0.2
epoch: 0
release: 1
summary: Flexible per-object authorization backend for Django
url: http://github.com/maraujop/django-rules
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6043ebe8-061e-4d64-93d2-8d75defdc23d
location_href: 00003488-python-django-rules/python-django-rules-0.2-1.src.rpm
checksum_type: sha256
description:
  h1(#abstract). django-rules

  django-rules is a Django authorization backend that offers a unified, per-object authorization management. It is quite different from other authorization backends in the way it lets you flexibly manage per-object permissions.

  In django-rules every rule adds an authorization constraint to a given model. The authorization constraint will check if the given user complies with the constraint (e.g. if the user has the right permissions to execute a certain action over an object, etc.). The authorization constraint can be a boolean attribute, property or method of the model, whichever you prefer for each rule :)


  h2(#philosophy). Philosophy

  django-rules strives to build a flexible and scalable authorization backend. Why is it better than other authorization backends out there?
  * The backend is simple, concise and compact. Less lines of code mean less complexity, faster execution and (hopefully :) less errors and bugs.
  * You can implement each authorization constraint as a boolean attribute, property or method of the model, whichever you prefer for each rule :) This way you will be able to re-implement how authorizations work at any time. It is dynamic and you know dynamic sounds way better than static :)
  * You don't have to add extra permissions or groups to your users. You simply program the constraints however you like them to be and then you assign them to the rules. Done!
  * You have fine granularity control over how the rules handle the authentication: one rule can be using an authorization constraint that uses LDAP while other rules call a web service (or anything you wish to hook in the authorization constraint).
  * Other per-object authorization backends create a row in a table for every object, every user and every permission combination. Even with an average-size site, you will have scalability nightmares, no matter how much you can cache.
  * Other authorization backends have to SELECT all permissions that a user has even if you only need to check one specific permission, making the memory footprint bigger.
  * Other authorization backends don't have a way to set centralized permissions, which are a real necessity in most projects out there.


  h2(#requirements). Requirements

  django-rules requires a proper installation of Django 1.2 (at least).


  h2(#installation). Installation

  h3(#pypi). From Pypi

  As simple as doing:

  <pre>
  pip install django-rules
  </pre>

  h3(#source). From source

  To install django-rules from source:

  <pre>
  git clone https://github.com/maraujop/django-rules/
  cd django-rules
  python setup.py install
  </pre>


  h2(#configuration). Configuration

  For django-rules to work, you have to hook it into your project:

  * Add it to the list of <code>INSTALLED_APPS</code> in <code>settings.py</code>:

  <pre>
  INSTALLED_APPS = (
      ...
      'django_rules',
  )
  </pre>

  * Add the django-rules authorization backend to the list of <code>AUTHENTICATION_BACKENDS</code> in <code>settings.py</code>:

  <pre>
  AUTHENTICATION_BACKENDS = (
      'django.contrib.auth.backends.ModelBackend', # Django's default auth backend
      'django_rules.backends.ObjectPermissionBackend',
  )
  </pre>

  * Run syncdb to update the database with the new django-rules models:

  <pre>
  python manage.py syncdb
  </pre>

  h2(#rules). Rules

  A rule represents a functional authorization constraint that restricts the actions that a certain user can carry out on a certain object (an instance of a Model).

  Every rule definition is composed of 6 parameters (3 compulsory and 3 optional):
  * <code>app_name</code>: The name of the app to which the rule applies.
  * <code>codename</code>: The name of the rule, _unique across all applications_. It should be a brief but distinctive name.
  * <code>model</code>: The name of the model associated with the rule.

  * <code>field_name</code> _(optional)_: The name of the boolean attribute, property or method of the model that implements the authorization constraint. If not set, it defaults to the value of the compulsory field <code>codename</code>.
  * <code>view_param_pk</code> _(optional)_: The view parameter's name to use for getting the primary key of the model. It is used in the decorated views for getting the actual instance of the model, the object where authorizations will be checked on. If not set, it defaults to the name of the primary key field in the model. Note that if the name of the parameter of the view that holds the value of the object's primary key doesn't match the name of the primary key of the model, the new name must be specified in this parameter (we will talk about this special case in "the section on Decorators":#decorators).
  * <code>description</code> _(optional)_: A brief (140 characters maximum) description explaining the expected behaviour of the authorization constraint. Although optional, it is considered a Good Practice ^TM^ and should always be used.

  The rules should be created per-Django application. That is, under the root directory of the Django-application in which you want to create rules, you should have a <code>rules.py</code> containing only the declarations of those rules specific to that Django-application.

  Once you have defined the rules in <code>rules.py</code>, you will want to activate them. For every rule that you want to activate you *must* add a registration point for it by calling <code>django_rules.utils.register</code> in <code>rules.py</code>.

  Finally, once you have <code>rules.py</code> properly set up, you will want to sync the rules to the database. In your Django project you will have to run <code>sync_rules</code> command:

  <pre>
  python manage.py sync_rules
  </pre>

  This command will look for all your <code>rules.py</code> files under your <code>INSTALLED_APPS</code> and will sync the latest changes to the database, so you don't have to run <code>syncdb</code> or rebuild the full database at all.


  h2(#examples). Examples:


  h3(#ex1). Example 1: Creating a simple, compact rule for the Item model in the 'shipping' Django-application

  Let's image that, within the <code>shipping</code> Django-application, I have the following <code>models.py</code>:

  <pre>
  class Item(models.Model):
      supplier = models.ForeignKey(User)
      description = models.CharField(max_length = 50)
  </pre>

  Then, imagine that the business logic in our application has a functional authorization constraint for every item such as "An item can only be shipped by its supplier". Now, to comply with the functional authorization constraint we only have to create a simple rule.

  First, let's start by adding an authorization constraint to the Item model. Remember that we can use a method, a boolean attribute or a boolean-returning property. This time we will be using a method:

  <pre>
  class Item(models.Model):
      supplier = models.ForeignKey(User)
      description = models.CharField(max_length = 50)

      def can_ship(self, user_obj):
          """
          Checks if the given user_obj is the supplier of the item
          """
          return self.supplier == user_obj
  </pre>

  Then, to associate the authorization constraint with a rule, we have to set up the rule in the application's <code>rules.py</code> file:

  <pre>
  from django_rules import utils

  rules_list = [
      {'codename':'can_ship', 'model':'Item'},
  ]







  for rule in rules_list:
      utils.register(app_name='shipping', **rule)
  </pre>

  Finally, do not forget to sync the rules to make sure that all the new definitions, changes, etc. are synced to the database.

  <pre>
  python manage.py sync_rules
  </pre>


  h3(#ex2). Example 2: Creating a rule that doesn't follow the naming conventions

  Imagine that we would like to name our authorization constraints however we want. For example, let's change the previous Item model:

  <pre>
  class Item(models.Model):
      supplier = models.ForeignKey(User)
      description = models.CharField(max_length = 50)

      def isSameSupplier(self, user_obj):    #--> change in the name convention of the authorization constraint
          """
          Checks if the given user_obj is the supplier of the item
          """
          return self.supplier == user_obj
  </pre>

  Then, we would have to set up a more verbose rule in the application's <code>rules.py</code> file by using its additional optional fields. This time, only <code>field_name</code> would be needed but it is also Good Practice ^TM^ to give a brief <code>description</code>:

  <pre>
  from django_rules import utils

  rules_list = [
      {'codename':'can_ship', 'model':'Item', 'field_name':'isSameSupplier',
       'description':'Checks if the given user is the supplier of the item'},
  ]


  for rule in rules_list:
      utils.register(app_name='shipping', **rule)
  </pre>

  Again, do not forget to sync the rules to make sure that all the new definitions, changes, etc. are applied to the database.

  <pre>
  python manage.py sync_rules
  </pre>


  h3. Using your rules

  Once you have set up a rule that implements a functional authorization constraint, you can (and should :) use it in your application. It is really simple! In every place you want to enforce an authorization constraint on a user, you will simply make the following call:

  <pre>
  user_obj.has_perm(codename, model_obj)
  </pre>

  Following the previous "Example 1":#ex1, let's imagine that the application is already running with data in the database (at least one supplier and one item, both with ids equal to 1). Remember that we have already implemented, defined, registered and synced the following rule:

  <pre>
  {'codename':'can_ship', 'model':'Item'}
  </pre>

  Then, if we wanted to check whether a supplier can ship an item, we would only have to enforce the rule by doing:

  <pre>
  supplier = Supplier.objects.get(pk = 1)
  item = Item.objects.get(pk = 1)

  if supplier.has_perm('can_ship', item):
      print 'Yay! The supplier can ship the item! :)'
  </pre>

  Easy, right? :)


  h4. Details about the internal magic of django-rules

  Please note that what follows is a detailed explanation of how all the inner magic in django-rules flows. If you don't really care, please move along. You really don't need these details to be able to write rules and use django-rules effectively. However, if you are curious and want to know more, please pay great attention to the details below.

  Here is how all the pieces of the puzzle come together:
  * When you call <code>user_obj.has_perm(codename, model_obj)</code> (in the previous example, <code>supplier.has_perm('can_ship', item)</code>), Django handles the control over to the django-rules backend.
  * The django-rules backend will then try to match the <code>codename</code> with a rule. Note that we are requesting a rule with a <code>codename</code> of <code>'can_ship'</code> and a <code>model_obj</code> like the Model of the item object. Because in "Example 1":#ex1 we have defined the rule <code>{'codename':'can_ship', 'model':'Item'}</code>, there will be a match.
  * Then, django-rules will check whether <code>field_name</code> is an attribute, a property or a method, and will act accordingly. If <code>field_name</code> is a method, the django-rules backend will check if it requires just one user parameter or no parameter at all. Depending on the parameter requirements, it will execute <code>model_obj.field_name()</code> or <code>model_obj.field_name(user_obj)</code>. In our "Example 1":#ex1 we require a user parameter so it will execute <code>item.can_ship(supplier)</code>.
  * Finally, if the authorization constraint implemented in <code>field_name</code> is True or returns True, the constraint is considered fulfilled. Otherwise, you will not be authorized.


  h3. Details of using model methods in rules

  As we have seen, django-rules will check whether <code>field_name</code> is an attribute, a property or a method, and will act accordingly. You can create rules based on model's attributes and properties, which are more than fine for very simple cases but most of the time you will be setting <code>field_name</code> to a method in the model.

  It is important to note that this method is limited to having just one parameter (a user object) or no parameters at all. It cannot receive multiple arguments or an argument that is not an instance of User. Although this might seem like a limitation, we could not think of a use case where the rest of the information needed coudn't be retrieved from the user or the model object. If you get into a situation where this is limiting you, please get in touch and explain your problem so that we can think of how to get around it! :)

  Finally, you need to be aware of something very important: a method assigned to a rule (let's call them _rule methods_ from now on) *should never call any other method*. That is, they should be self-contained. This is to avoid a potential infinite recursion. Imagine a situation where the rule method calls another method that has _the same_ authorization constraint of the previous rule method. Boom! You just created an infinite loop. Run for your life! :)

  You may be thinking that you can control this but, trust me, it will get very difficult to maintain and scale. Things will not always be that simple, maybe you will end up calling a method that is later modified and ends up calling a helper function that triggers the same authorization loop. Yeah, I know. Indirection is a bitch :) Or, in other words "Great power comes with great responsibility". So beware of the infinite loop ;)


  h2(#decorators). Decorators

  If you like Python as much as I do, you will love decorators. Django has a <code>permission_required</code> decorator, so it felt natural that django-rules implemented an <code>object_permission_required</code> decorator.

  Imagine that for our "Example 1":#ex1 we have the following code in <code>views.py</code>:

  <pre>
  def ship_item(request, id):
      item = Item.objects.get(pk = id)

      if request.user.has_perms('can_ship', item):
          return HttpResponse('success')

      return HttpResponse('error')
  </pre>

  We could easily decorate the view to make the method much more compact and easy to read:

  <pre>
  from django_rules import object_permission_required

  @object_permission_required('can_ship')
  def ship_item(request, id):
      return HttpResponse('Item successfully shipper! :)')
  </pre>

  The magic of the decorator is very cool indeed. First, it matches the rule and gets the type of model from it. Then, it gets the <code>id</code> parameter from the view's kwargs and instantiates a Model object with <code>item = model.objects.get(pk = id)</code>. Finally, it can call the <code>request.user.has_perm('can_ship', item)</code> for you and redirect to a fail page if the constraint is not fulfilled.

  Note how we have maintained the name of the model's primary key in the parameters of the view. If the parameter has a name that doesn't match the name of the primary key in the model, remember that we will have to add another optional parameter to the rule. From "the section on Rules:":#rules
  * <code>view_param_pk</code> _(optional)_: The view parameter's name to use for getting the primary key of the model. It is used in the decorated views for getting the actual instance of the model. If not set, it defaults to the name of the primary key field in the model. Note that if the name of the parameter of the view that holds the value of the object's primary key doesn't match the name of the primary key of the model, the new name must be specified in this parameter.

  For example, if we modify the parameter of the view:

  <pre>
  from django_rules import object_permission_required

  @object_permission_required('can_ship')
  def ship_item(request, my_item_code):  #--> change in the naming of the parameter in the view
      return HttpResponse('success')
  </pre>

  We would have to specify the <code>view_param_pk</code> in the rule definition:

  <pre>
  rules_list = [
      {'codename': 'can_ship', 'model': 'Item', 'view_param_pk': 'my_item_code',
       'description': 'Checks if the given user is the supplier of the item'},
  ]
  </pre>


  The <code>object_permission_required</code> decorator can receive 4 arguments:

  <pre>
  @object_permission_required('can_ship', return_403=True)
  @object_permission_required('can_ship', redirect_url='/more/foo/bar/')
  @object_permission_required('can_ship', redirect_field_name='myFooField')
  @object_permission_required('can_ship', login_url='/foo/bar/')
  </pre>

  By default:
  * <code>return_403</code> is set to False.
  * <code>redirect_url</code> is set to an empty string.
  * <code>redirect_field_name</code> is set to django.contrib.auth's REDIRECT_FIELD_NAME.
  * <code>login_url</code> is set to <code>settings.LOGIN_URL</code>.

  Thus, if the authorization constraint is not fulfilled, the decorator will default to a redirect to the login page in Django-style :)

  Also, note that a couple of the parameters have a specificity. Namely:
  * if <code>return_403</code> is set to True it will override the rest of the parameters and the decorator will return a HttpResponseForbidden.
  * if <code>redirect_url</code> is set to a URL, it will override that of <code>login_url</code>.

  Finally, it is important to note a tricky detail regarding the use of the decorator to guard the access of those methods that are not directly exposed as views mapped to external URLs. When a view method is an entry point through URLs (that is, if your view method is mapped directly to one of the <code>urls.py</code> entries), Django parses the URL and passes the parameters to the view as <code>kwargs</code>. Thus, if you want to use the <code>object_permission_required</code> decorator over an internal method (a method that is called inside one of those external views or somewhere else in your code) you must use <code>kwargs</code> when passing the parameters.

  Let's see an example:

  <pre>
  def item_shipper(request, id):
      internal_code = 'XXX-' + my_item_code
      return _ship_item(request, id=internal_code)    # instead of doing return _ship_item(request, internal_code)

  @object_permission_required('can_ship')
  def _ship_item(request, id)
      return HttpResponse('success')
  </pre>

  h2(#centralizedpermissions). Centralized Permissions

  django-rules has a central authorization dispatcher that is aimed towards a very common need in real life projects: the special, privileged groups such as administrators, user-support staff, etc., that have permissions to override certain aspects of the authorization constraints in the application. For such cases, django-rules has a way to let you bypass its authorization system for whatever reasons you have.

  To set up centralized permissions, you will need to set in your project settings the variable <code>CENTRAL_AUTHORIZATIONS</code> pointing to a module. Within that module, you will have to define a a boolean-returning function named <code>central_authorizations</code> accepting exactly two parameters:
  * <code>user_obj</code>: the user object.
  * <code>codename</code>: the codename of the rule we will be overriden. It is very useful to refine the permissions of a special user "a la ACL".
  Note that, although the naming of the parameters doesn't really matter, the order does. The first parameter will receive a user object, and the second parameter, the codename of the rule.

  This <code>central_authorizations()</code> function will be called *before* any other rule, so you can override all of them here.

  For example, in <code>settings.py</code> you will add:

  <pre>
  CENTRAL_AUTHORIZATIONS = 'myProjectFoo.utils'
  </pre>

  And then, within myProjectFoo, in <code>utils.py</code>, you will implement the <code>central_authorizations()</code> function with the overrides for the special users.

  Imagine you want to give some special access to user support staff that will be able to access some private fields in the profile (for example, email and age) that generally are hidden to regular users of the application. They are user support, so they should not be able to override certain things in the application. Yet, you also want your über-admins (generally the developers) to be able to access anything within the application so that they can code and test quickly while developing.

  In such case, you can write the following <code>central_authorizations()</code> function:

  <pre>
  def central_authorizations(user_obj, codename):
      """
      This function will be called *before* any other rule,
      so you can override all of the permissions here.
      """
      isAuthorized = False

      if user_obj.get_profile().isUberAdmin():
          isAuthorized = True
      elif user_obj.get_profile().isUserSupport() and codename in ['can_see_full_profile', 'can_delete_item']:
          isAuthorized = True

      return isAuthorized
  </pre>

  As you can imagine, everything that is checked in <code>central_authorizations</code> is global to the *whole* project.


  h2. Status and testing

  django-rules is meant to be a security application. Thus, it has been thoroughly tested. It comes with a battery of tests that tries to cover all of the available funcionality. However, if you come across a bug or an irregular situation, feel free to report it through the "Github bug tracker":https://github.com/maraujop/django-rules/issues.

  Finally, the application comes geared with many different exceptions that will make sure rules are created properly. They are also aimed to keep the security of your application away from negligence. Manage the exceptions wisely and you will be a happy and secure coder, as security is kept away from possible neglicence. You should manage them carefuly.


  h3. Testing django-rules

  To run tests, get into tests directory and execute:

  <pre>
  ./runtests.py
  </pre>

  It should always say OK. If not, there is a broken test that I hope you will be reporting soon :)


  h2. Need more examples?

  I have done my best trying to explain the concept behind django-rules but, if you would rather look at more code examples, I am sure you will find the "code in the tests":https://github.com/maraujop/django-rules/blob/master/django_rules/tests/test_core.py quite useful :)


  h2. More Documentation

  In case you want to know where all this "per-object authentication backend in Django" came to exist, you should at least read the following links:
  * A great article about "per-object permission backends in Django":http://djangoadvent.com/1.2/object-permissions/ by Florian Apolloner
  * Also, check the explanation of the changes introduced when fixing the "django ticket #11010":http://code.djangoproject.com/ticket/11010

  Finally, my most sincere appreciation goes to everybody that contributes to the wonderful Django development framework and also to the rest of developers and committers that build django-rules with their help. Respect! :)


pkgId: f114362e3215620b0e9faeff478e11d6239e5a6be548a78f077b30cb897f3a2d
name: python-django-sass-processor
arch: src
version: 1.2.2
epoch: 0
release: 1
summary: SASS processor to compile SCSS files into *.css, while rendering, or offline.
url: https://github.com/jrief/django-sass-processor
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1884bd9f-95fc-439e-86a4-e9519fac430a
location_href: 00013069-python-django-sass-processor/python-django-sass-processor-1.2.2-1.src.rpm
checksum_type: sha256
description:
  Annoyed having to run a Compass, Grunt or Gulp daemon while developing Django projects?

  Well, then this app is for you! Compile SASS/SCSS files on the fly without having to manage
  third party services nor special IDE plugins.

  [![Build Status](https://github.com/jrief/django-sass-processor/actions/workflows/tests.yml/badge.svg)](https://github.com/jrief/django-sass-processor/actions)
  [![PyPI](https://img.shields.io/pypi/pyversions/django-sass-processor.svg)]()
  [![PyPI version](https://img.shields.io/pypi/v/django-sass-processor.svg)](https://pypi.python.org/pypi/django-sass-processor)
  [![PyPI](https://img.shields.io/pypi/l/django-sass-processor.svg)]()
  [![Downloads](https://img.shields.io/pypi/dm/django-sass-processor.svg)](https://pypi.python.org/pypi/django-sass-processor)
  [![Twitter Follow](https://img.shields.io/twitter/follow/shields_io.svg?style=social&label=Follow&maxAge=2592000)](https://twitter.com/jacobrief)




  * Refer SASS/SCSS files directly from your sources, instead of referring a compiled CSS file,
  having to rely on another utility which creates them from SASS/SCSS files, hidden in
  your source tree.
  * Use Django's `settings.py` for the configuration of paths, box sizes etc., instead of having another
  SCSS specific file (typically `_variables.scss`), to hold these.
  * Extend your SASS functions by calling Python functions directly out of your Django project.
  * View SCSS errors directly in the debug console of your Django's development server.

  **django-sass-processor** converts `*.scss` or `*.sass` files into `*.css` while rendering
  templates. For performance reasons this is done only once, since the preprocessor keeps track on
  the timestamps and only recompiles, if any of the imported SASS/SCSS files is younger than the
  corresponding generated CSS file.



  This Django app provides a templatetag `{% sass_src 'path/to/file.scss' %}`, which can be used
  instead of the built-in templatetag `static`. This templatetag also works inside Jinja2 templates.

  If SASS/SCSS files shall be referenced through the `Media` class, or `media` property, the SASS
  processor can be used directly.

  Additionally, **django-sass-processor** is shipped with a management command, which can convert
  the content of all occurrences inside the templatetag `sass_src` as an offline operation. Hence
  the **libsass** compiler is not required in a production environment.

  During development, a [sourcemap](https://developer.chrome.com/devtools/docs/css-preprocessors) is
  generated along side with the compiled `*.css` file. This allows to debug style sheet errors much
  easier.

  With this tool, you can safely remove your Ruby installations "Compass" and "SASS" from your Django
  projects. You neither need any directory "watching" daemons based on node.js.



  On GitHub:

  https://github.com/jrief/django-sass-processor

  Please use the issue tracker to report bugs or propose new features.



  ```
  pip install libsass django-compressor django-sass-processor
  ```

  `django-compressor` is required only for offline compilation, when using the command
  `manage.py compilescss`.

  `libsass` is not required on the production environment, if SASS/SCSS files have been precompiled
  and deployed using offline compilation.



  In `settings.py` add to:

  ```python
  INSTALLED_APPS = [
      ...
      'sass_processor',
      ...
  ]
  ```

  **django-sass-processor** is shipped with a special finder, to locate the generated `*.css` files
  in the directory referred by `SASS_PROCESSOR_ROOT` (or, if unset `STATIC_ROOT`). Just add it to
  your `settings.py`. If there is no `STATICFILES_FINDERS` in your `settings.py` don't forget
  to include the **Django** [default finders](https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-STATICFILES_FINDERS).

  ```python
  STATICFILES_FINDERS = [
      'django.contrib.staticfiles.finders.FileSystemFinder',
      'django.contrib.staticfiles.finders.AppDirectoriesFinder',
      'sass_processor.finders.CssFinder',
      ...
  ]
  ```

  Optionally, add a list of additional search paths, the SASS compiler may examine when using the
  `@import "...";` statement in SASS/SCSS files:

  ```python
  import os

  SASS_PROCESSOR_INCLUDE_DIRS = [
      os.path.join(PROJECT_PATH, 'extra-styles/scss'),
      os.path.join(PROJECT_PATH, 'node_modules'),
  ]
  ```

  Additionally, **django-sass-processor** will traverse all installed Django apps (`INSTALLED_APPS`)
  and look into their static folders. If any of them contain a file matching the regular expression
  pattern `^_.+\.(scss|sass)$` (read: filename starts with an underscore and is of type `scss` or
  `sass`), then that app specific static folder is added to the **libsass** include dirs. This
  feature can be disabled in your settings with:

  ```python
  SASS_PROCESSOR_AUTO_INCLUDE = False
  ```

  If inside of your SASS/SCSS files, you also want to import (using `@import "path/to/scssfile";`)
  files which do not start with an underscore, then you can configure another Regex pattern in your
  settings, for instance:

  ```python
  SASS_PROCESSOR_INCLUDE_FILE_PATTERN = r'^.+\.scss$'
  ```

  will look for all files of type `scss`. Remember that SASS/SCSS files which start with an
  underscore, are intended to be imported by other SASS/SCSS files, while files starting with a
  letter or number are intended to be included by the HTML tag
  `<link href="{% sass_src 'path/to/file.scss' %}" ...>`.

  During development, or when `SASS_PROCESSOR_ENABLED = True`, the compiled file is placed into the
  folder referenced by `SASS_PROCESSOR_ROOT` (if unset, this setting defaults to `STATIC_ROOT`).
  Having a location outside of the working directory prevents to pollute your local `static/css/...`
  directories with auto-generated files. Therefore assure, that this directory is writable by the
  Django runserver.




  Integer `SASS_PRECISION` sets floating point precision for output css. libsass'
  default is `5`. Note: **bootstrap-sass** requires `8`, otherwise various
  layout problems _will_ occur.

  ```python
  SASS_PRECISION = 8
  ```

  `SASS_OUTPUT_STYLE` sets coding style of the compiled result, one of `compact`,
  `compressed`, `expanded`, or `nested`. Default is `nested` for `DEBUG`
  and `compressed` in production.

  Note: **libsass-python** 0.8.3 has [problem encoding result while saving on
  Windows](https://github.com/dahlia/libsass-python/pull/82), the issue is already
  fixed and will be included in future `pip` package release, in the meanwhile
  avoid `compressed` output style.

  ```python
  SASS_OUTPUT_STYLE = 'compact'
  ```



  `sass_processor.jinja2.ext.SassSrc` is a Jinja2 extension. Add it to your Jinja2 environment to enable the tag `sass_src`, there is no need for a `load` tag. Example of how to add your Jinja2 environment to Django:

  In `settings.py`:

  ```python
  TEMPLATES = [{
      'BACKEND': 'django.template.backends.jinja2.Jinja2',
      'DIRS': [],
      'APP_DIRS': True,
      'OPTIONS': {
          'environment': 'yourapp.jinja2.environment'
      },
      ...
  }]
  ```

  Make sure to add the default template backend, if you're still using Django templates elsewhere.
  This is covered in the [Upgrading templates documentation](https://docs.djangoproject.com/en/stable/ref/templates/upgrading/).

  In `yourapp/jinja2.py`:

  ```python

  from __future__ import absolute_import

  from jinja2 import Environment


  def environment(**kwargs):
      extensions = [] if 'extensions' not in kwargs else kwargs['extensions']
      extensions.append('sass_processor.jinja2.ext.SassSrc')
      kwargs['extensions'] = extensions

      return Environment(**kwargs)
  ```

  If you want to make use of the `compilescss` command, then you will also have to add the following to your settings:

  ```python
  from yourapp.jinja2 import environment

  COMPRESS_JINJA2_GET_ENVIRONMENT = environment
  ```






  ```django
  {% load sass_tags %}

  <link href="{% sass_src 'myapp/css/mystyle.scss' %}" rel="stylesheet" type="text/css" />
  ```

  The above template code will be rendered as HTML

  ```html
  <link href="/static/myapp/css/mystyle.css" rel="stylesheet" type="text/css" />
  ```

  You can safely use this templatetag inside a [Sekizai](https://django-sekizai.readthedocs.io/)'s
  `{% addtoblock "css" %}` statement.



  In Python code, you can access the API of the SASS processor directly. This for instance is useful
  in Django's admin or form framework.

  ```python
  from sass_processor.processor import sass_processor

  class SomeAdminOrFormClass(...):
      ...
      class Media:
          css = {
              'all': [sass_processor('myapp/css/mystyle.scss')],
          }
  ```



  Writing SCSS shall be fast and easy and you should not have to care, whether to add vendor specific
  prefixes to your CSS directives. Unfortunately there is no pure Python package to solve this, but
  with a few node modules, we can add this to our process chain.

  As superuser install

  ```shell
  npm install -g npx
  ```

  and inside your project root, install

  ```shell
  npm install postcss-cli autoprefixer
  ```

  Check that the path of `node_modules` corresponds to its entry in the settings directive
  `STATICFILES_DIRS` (see below).

  In case `npx` can not be found in your system path, use the settings directive
  `NODE_NPX_PATH = /path/to/npx` to point to that executable.

  If everything is setup correctly, **django-sass-processor** adds all required vendor prefixes to
  the compiled CSS files. For further information, refer to the
  [Autoprefixer](https://github.com/postcss/autoprefixer) package.

  To disable autoprefixing, set `NODE_NPX_PATH = None`.

  **Important note**: If `npx` is installed, but `postcss` and/or `autoprefixer` are missing
  in the local `node_modules`, setting `NODE_NPX_PATH` to `None` is manadatory, otherwise
  **django-sass-processor** does not know how to postprocess the generated CSS files.



  If you want to precompile all occurrences of your SASS/SCSS files for the whole project, on the
  command line invoke:

  ```shell
  ./manage.py compilescss
  ```

  This is useful for preparing production environments, where SASS/SCSS files can't be compiled on
  the fly.

  To simplify the deployment, the compiled `*.css` files are stored side-by-side with their
  corresponding SASS/SCSS files. After compiling the files run

  ```shell
  ./manage.py collectstatic
  ```

  as you would in a normal deployment.

  In case you don't want to expose the SASS/SCSS files in a production environment,
  deploy with:

  ```shell
  ./manage.py collectstatic --ignore=*.scss
  ```

  To get rid of the compiled `*.css` files in your local static directories, simply reverse the
  above command:

  ```shell
  ./manage.py compilescss --delete-files
  ```

  This will remove all occurrences of previously generated `*.css` files.

  Or you may compile results to the `SASS_PROCESSOR_ROOT` directory directy (if not specified - to
  `STATIC_ROOT`):

  ```shell
  ./manage.py compilescss --use-storage
  ```

  Combine with `--delete-files` switch to purge results from there.

  If you use an alternative templating engine set its name in `--engine` argument. Currently
  `django` and `jinja2` are supported, see
  [django-compressor documentation](http://django-compressor.readthedocs.org/en/latest/) on how to
  set up `COMPRESS_JINJA2_GET_ENVIRONMENT` to configure jinja2 engine support.

  During offline compilation **django-sass-processor** parses all Python files and looks for
  invocations of `sass_processor('path/to/sassfile.scss')`. Therefore the string specifying
  the filename must be hard coded and shall not be concatenated or being somehow generated.



  By default, **django-sass-processor** will locate SASS/SCSS files from .html templates,
  but you can extend or override this behavior in your settings with:

  ```python
  SASS_TEMPLATE_EXTS = ['.html','.jade']
  ```



  In SASS, a nasty problem is to set the correct include paths for icons and fonts. Normally this is
  done through a `_variables.scss` file, but this inhibits a configuration through your projects
  `settings.py`.

  To avoid the need for duplicate configuration settings, **django-sass-processor** offers a SASS
  function to fetch any arbitrary configuration directive from the project's `settings.py`. This
  is specially handy to set the include path of your Glyphicons font directory. Assume, Bootstrap-SASS
  has been installed using:

  ```shell
  npm install bootstrap-sass
  ```

  then locate the directory named `node_modules` and add it to your settings, so that your fonts are
  accessible through the Django's `django.contrib.staticfiles.finders.FileSystemFinder`:

  ```python
  STATICFILES_DIRS = [
      ...
      ('node_modules', '/path/to/your/project/node_modules/'),
      ...
  ]

  NODE_MODULES_URL = STATIC_URL + 'node_modules/'
  ```

  With the SASS function `get-setting`, it is possible to override any SASS variable with a value
  configured in the project's `settings.py`. For the Glyphicons font search path, add this to your
  `_variables.scss`:

  ```scss
  $icon-font-path: unquote(get-setting(NODE_MODULES_URL) + "bootstrap-sass/assets/fonts/bootstrap/");
  ```

  and `@import "variables";` whenever you need Glyphicons. You then can safely remove any font
  references, such as `<link href="/path/to/your/fonts/bootstrap/glyphicons-whatever.ttf" ...>`
  from you HTML templates.




  It is even possible to call Python functions from inside any module. Do this by adding
  `SASS_PROCESSOR_CUSTOM_FUNCTIONS` to the project's `settings.py`. This shall contain a mapping
  of SASS function names pointing to a Python function name.

  Example:

  ```python
  SASS_PROCESSOR_CUSTOM_FUNCTIONS = {
      'get-color': 'myproject.utils.get_color',
  }
  ```

  This allows to invoke Python functions out of any `*.scss` file.

  ```scss
  $color: get-color(250, 10, 120);
  ```

  Here we pass the parameters '250, 10, 120' into the function `def get_color(red, green, blue)`
  in Python module `myproject.utils`. Note that this function receives the values as `sass.Number`,
  hence extract values using `red.value`, etc.

  If one of these customoized functions returns a value, which is not a string, then convert it
  either to a Python string or to a value of type `sass.SassNumber`. For other types, refer to their
  documentation.

  Such customized functions must accept parameters explicilty, otherwise `sass_processor` does not
  know how to map them. Variable argument lists therefore can not be used.




  Whenever **django-sass-processor** runs in debug mode and fails to compile a SASS/SCSS file, it
  raises a `sass.CompileError` exception. This shows the location of the error directly on the
  Django debug console and is very useful during development.

  This behaviour can be overridden using the settings variable `SASS_PROCESSOR_FAIL_SILENTLY`.
  If it is set to `True`, instead of raising that exception, the compilation error message is send
  to the Django logger.




  Under the hood, SASS processor will use any storage configured in your settings as `STATICFILES_STORAGE`.
  This means you can use anything you normally use for serving static files, e.g. S3.

  A custom Storage class can be used if your deployment needs to serve generated CSS files from elsewhere,
  e.g. when your static files storage is not writable at runtime and you nede to re-compile CSS
  in production. To use a custom storage, configure it in `SASS_PROCESSOR_STORAGE`. You can also
  configure a dictionary with options that will be passed to the storage class as keyword arguments
  in `SASS_PROCESSOR_STORAGE_OPTIONS` (e.g. if you want to use `FileSystemStorage`, but with
  a different `location` or `base_url`:

  ```python
  SASS_PROCESSOR_STORAGE = 'django.core.files.storage.FileSystemStorage'
  SASS_PROCESSOR_STORAGE_OPTIONS = {
      'location': '/srv/media/generated',
      'base_url': 'https://media.myapp.example.com/generated'
  }
  ```




  Using the S3 storage backend from [django-storages](https://django-storages.readthedocs.io/en/latest/)
  with its regular configuration (if you do not otherwise use it for service static files):

  ```python
  SASS_PROCESSOR_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
  ```




  If you are deploying to [Heroku](https://www.heroku.com/), use the
  [heroku-buildpack-django-sass](https://elements.heroku.com/buildpacks/drpancake/heroku-buildpack-django-sass)
  buildpack to automatically compile scss for you.




  To run the tests locally, clone the repository, and, in your local copy, create a new virtualenv.
  these commands:

  ```shell
  python -m pip install --upgrade pip
  pip install Django
  pip install -r tests/requirements.txt
  python -m pytest tests
  ```




  Brian wrote a nice artice on
  [how to easily use SASS/SCSS with Django](https://engineertodeveloper.com/how-to-easily-use-sass-scss-with-django/).


pkgId: f41f43f40000d0f2454c67441cb79febd1bb859345ace667167bff1a383fb51e
name: python-django-sendgrid-v5
arch: src
version: 1.2.2
epoch: 0
release: 1
summary: An implementation of Django's EmailBackend compatible with sendgrid-python v5+
url: https://github.com/sklarsa/django-sendgrid-v5
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-049f24b1-d0a9-4a97-9da3-811ef0fbc635
location_href: 00012469-python-django-sendgrid-v5/python-django-sendgrid-v5-1.2.2-1.src.rpm
checksum_type: sha256
description:
  [![Latest Release](https://img.shields.io/pypi/v/django-sendgrid-v5.svg)](https://pypi.python.org/pypi/django-sendgrid-v5/)

  This package implements an email backend for Django that relies on sendgrid's REST API for message delivery.

  It is under active development, and pull requests are more than welcome\!

  To use the backend, simply install the package (using pip), set the `EMAIL_BACKEND` setting in Django, and add a `SENDGRID_API_KEY` key (set to the appropriate value) to your Django settings.



  1. `pip install django-sendgrid-v5`
  2. In your project's settings.py script:
      1. Set `EMAIL_BACKEND = "sendgrid_backend.SendgridBackend"`
      2. Set the SENDGRID\_API\_KEY in settings.py to your api key that was provided to you by sendgrid. `SENDGRID_API_KEY = os.environ["SENDGRID_API_KEY"]`



  1. To toggle sandbox mode (when django is running in DEBUG mode), set `SENDGRID_SANDBOX_MODE_IN_DEBUG = True/False`.
      1. To err on the side of caution, this defaults to True, so emails sent in DEBUG mode will not be delivered, unless this setting is explicitly set to False.
  2. `SENDGRID_ECHO_TO_STDOUT` will echo to stdout or any other file-like
      object that is passed to the backend via the `stream` kwarg.
  3. `SENDGRID_TRACK_EMAIL_OPENS` - defaults to true and tracks email open events via the Sendgrid service. These events are logged in the Statistics UI, Email Activity interface, and are reported by the Event Webhook.
  4. `SENDGRID_TRACK_CLICKS_HTML` - defaults to true and, if enabled in your Sendgrid account, will tracks click events on links found in the HTML message sent.
  5. `SENDGRID_TRACK_CLICKS_PLAIN` - defaults to true and, if enabled in your Sendgrid account, will tracks click events on links found in the plain text message sent.





  ```python
  from django.core.mail import send_mail

  send_mail(
      'Subject here',
      'Here is the message.',
      'from@example.com',
      ['to@example.com'],
      fail_silently=False,
  )
  ```



  First, create a [dynamic template](https://mc.sendgrid.com/dynamic-templates) and copy the ID.

  ```python
  from django.core.mail import EmailMessage

  msg = EmailMessage(
    from_email='to@example.com',
    to=['to@example.com'],
  )
  msg.template_id = "your-dynamic-template-id"
  msg.dynamic_template_data = {
    "title": foo
  }
  msg.send(fail_silently=False)
  ```



  ```python
  from django.core.mail import EmailMessage

  msg = EmailMessage(
    from_email='to@example.com',
    to=['to@example.com'],
    cc=['cc@example.com'],
    bcc=['bcc@example.com'],
  )



  msg.custom_args = {'arg1': 'value1', 'arg2': 'value2'}


  msg.reply_to = 'reply-to@example.com'



  msg.send_at = 1600188812



  msg.template_id = "your-dynamic-template-id"
  msg.dynamic_template_data = {  # Sendgrid v6+ only
    "title": foo
  }
  msg.substitutions = {
    "title": bar
  }



  msg.asm = {'group_id': 123, 'groups_to_display': ['group1', 'group2']}



  msg.categories = ['category1', 'category2']



  msg.ip_pool_name = 'my-ip-pool'


  msg.send(fail_silently=False)
  ```



  **How to change a Sender's Name ?**


  `from_email="John Smith <john.smith@example.org>"`
  You can just include the name in the from_email field of the _```EmailMessage```_ class

  ```
  msg = EmailMessage(
    from_email='Sender Name <from@example.com>',
    to=['to@example.com'],
  )
  ```

  **How to make mails to multiple users private (hide all the email addresses to which the mail is sent) to each person (personalization) ?**


  Setting the `make_private` attribute to `True` will help us achieve it
  ```
  msg = EmailMessage(
    from_email='Sender Name <from@example.com>',
    to=['to@example.com','abc@example.com','xyz@example.com'],
  )
  msg.make_private = True
  ```



  - Marcelo Canina [(@marcanuy)](https://github.com/marcanuy) wrote a great article demonstrating how to integrate `django-sendgrid-v5` into your Django application on his site: [https://simpleit.rocks/python/django/adding-email-to-django-the-easiest-way/](https://simpleit.rocks/python/django/adding-email-to-django-the-easiest-way/)
  - RX-36 [(@DevWoody856)](https://github.com/DevWoody856) demonstrates how to use `django-sendgrid-v5` to make a contact form for your web application: https://rx-36.life/post/create-a-contact-form-using-sendgrid-in-django/




  [![Stargazers over time](https://starchart.cc/sklarsa/django-sendgrid-v5.svg)](https://starchart.cc/sklarsa/django-sendgrid-v5)


pkgId: bab9a309df796fe838a57e191340909a7b2c3b4b805fab9ee3a1bcf4bb0cabe1
name: python-django-settings-export
arch: src
version: 1.2.1
epoch: 0
release: 1
summary: This Django app allows you to export certain settings to your templates.
url: https://github.com/jkbrzt/django-settings-export
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5dd1c10e-e40e-4ad6-b95e-44a8e58b97ef
location_href: 00012415-python-django-settings-export/python-django-settings-export-1.2.1-1.src.rpm
checksum_type: sha256
description:
      $ pip install django-settings-export
  Add ``'django_settings_export.settings_export'`` to
  template context processor list in your ``settings.py``:
  **Django 1.8 and newer:**
      TEMPLATES = [
          {
              
              'OPTIONS': {
                  'context_processors': [
                      
                      'django_settings_export.settings_export',
                  ],
              },
          },
      ]
  **Django older than 1.8:**
      TEMPLATE_CONTEXT_PROCESSORS = [
          
          'django_settings_export.settings_export',
      ]


pkgId: 94ba1b5305cad2279d45d6a9e5df633e123657f119f69e9494b784895b566550
name: python-django-silk
arch: src
version: 5.0.3
epoch: 0
release: 1
summary: Silky smooth profiling for the Django Framework
url: https://github.com/jazzband/django-silk
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d4518a91-114b-405a-9182-7b6878a8c49d
location_href: 00010690-python-django-silk/python-django-silk-5.0.3-1.src.rpm
checksum_type: sha256
description:
  [![GitHub Actions](https://github.com/jazzband/django-silk/workflows/Test/badge.svg)](https://github.com/jazzband/django-silk/actions)
  [![GitHub Actions](https://codecov.io/gh/jazzband/django-silk/branch/master/graph/badge.svg)](https://codecov.io/gh/jazzband/django-silk)
  [![PyPI Download](https://img.shields.io/pypi/v/django-silk.svg)](https://pypi.python.org/pypi/django-silk)
  [![PyPI Python Versions](https://img.shields.io/pypi/pyversions/django-silk.svg)](https://pypi.python.org/pypi/django-silk)
  [![Supported Django versions](https://img.shields.io/pypi/djversions/django-silk.svg)](https://pypi.python.org/pypi/django-silk)
  [![Jazzband](https://jazzband.co/static/img/badge.svg)](https://jazzband.co/)

  Silk is a live profiling and inspection tool for the Django framework. Silk intercepts and stores HTTP requests and database queries before presenting them in a user interface for further inspection:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/1.png" width="720px"/>



  * [Requirements](#requirements)
  * [Installation](#installation)
  * [Features](#features)
  * [Configuration](#configuration)
    * [Authentication/Authorisation](#authenticationauthorisation)
    * [Request/Response bodies](#requestresponse-bodies)
    * [Meta-Profiling](#meta-profiling)
    * [Recording a fraction of requests](#recording-a-fraction-of-requests)
    * [Limiting request/response data](#limiting-requestresponse-data)
    * [Clearing logged data](#clearing-logged-data)
  * [Contributing](#contributing)
    * [Development Environment](#development-environment)



  Silk has been tested with:

  * Django: 3.2, 4.0, 4.1
  * Python: 3.7, 3.8, 3.9, 3.10, 3.11



  Via pip into a `virtualenv`:

  ```bash
  pip install django-silk
  ```

  In `settings.py` add the following:

  ```python
  MIDDLEWARE = [
      ...
      'silk.middleware.SilkyMiddleware',
      ...
  ]

  INSTALLED_APPS = (
      ...
      'silk'
  )
  ```

  **Note:** The middleware placement is sensitive. If the middleware before `silk.middleware.SilkyMiddleware` returns from `process_request` then `SilkyMiddleware` will never get the chance to execute. Therefore you must ensure that any middleware placed before never returns anything from `process_request`. See the [django docs](https://docs.djangoproject.com/en/dev/topics/http/middleware/#process-request) for more information on this.

  **Note:** If you are using `django.middleware.gzip.GZipMiddleware`, place that **before** `silk.middleware.SilkyMiddleware`, otherwise you will get an encoding error.

  If you want to use custom middleware, for example you developed the subclass of `silk.middleware.SilkyMiddleware`, so you can use this combination of settings:

  ```python

  SILKY_MIDDLEWARE_CLASS = 'path.to.your.middleware.MyCustomSilkyMiddleware'


  MIDDLEWARE = [
      ...
      SILKY_MIDDLEWARE_CLASS,
      ...
  ]
  ```

  To enable access to the user interface add the following to your `urls.py`:

  ```python
  urlpatterns += [path('silk/', include('silk.urls', namespace='silk'))]
  ```

  before running migrate:

  ```bash
  python manage.py migrate

  python manage.py collectstatic
  ```


  Silk will automatically begin interception of requests and you can proceed to add profiling
  if required. The UI can be reached at `/silk/`



  Via [github tags](https://github.com/jazzband/django-silk/releases):

  ```bash
  pip install https://github.com/jazzband/silk/archive/<version>.tar.gz
  ```

  You can install from master using the following, but please be aware that the version in master
  may not be working for all versions specified in [requirements](#requirements)

  ```bash
  pip install -e git+https://github.com/jazzband/django-silk.git#egg=django-silk
  ```



  Silk primarily consists of:

  * Middleware for intercepting Requests/Responses
  * A wrapper around SQL execution for profiling of database queries
  * A context manager/decorator for profiling blocks of code and functions either manually or dynamically.
  * A user interface for inspection and visualisation of the above.



  The Silk middleware intercepts and stores requests and responses in the configured database.
  These requests can then be filtered and inspecting using Silk's UI through the request overview:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/1.png" width="720px"/>

  It records things like:

  * Time taken
  * Num. queries
  * Time spent on queries
  * Request/Response headers
  * Request/Response bodies

  and so on.

  Further details on each request are also available by clicking the relevant request:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/2.png" width="720px"/>



  Silk also intercepts SQL queries that are generated by each request. We can get a summary on things like
  the tables involved, number of joins and execution time (the table can be sorted by clicking on a column header):

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/3.png" width="720px"/>

  Before diving into the stack trace to figure out where this request is coming from:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/5.png" width="720px"/>



  Turn on the SILKY_PYTHON_PROFILER setting to use Python's built-in cProfile profiler. Each request will be separately profiled and the profiler's output will be available on the request's Profiling page in the Silk UI.

  ```python
  SILKY_PYTHON_PROFILER = True
  ```

  If you would like to also generate a binary `.prof` file set the following:

  ```python
  SILKY_PYTHON_PROFILER_BINARY = True
  ```

  When enabled, a graph visualisation generated using [gprof2dot](https://github.com/jrfonseca/gprof2dot) and [viz.js](https://github.com/almende/vis) is shown in the profile detail page:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/10.png" width="720px"/>


  A custom storage class can be used for the saved generated binary `.prof` files:

  ```python
  SILKY_STORAGE_CLASS = 'path.to.StorageClass'
  ```

  The default storage class is `silk.storage.ProfilerResultStorage`, and when using that you can specify a path of your choosing. You must ensure the specified directory exists.

  ```python

  SILKY_PYTHON_PROFILER_RESULT_PATH = '/path/to/profiles/'
  ```

  A download button will become available with a binary `.prof` file for every request. This file can be used for further analysis using [snakeviz](https://github.com/jiffyclub/snakeviz) or other cProfile tools


  Silk can also be used to profile specific blocks of code/functions. It provides a decorator and a context
  manager for this purpose.

  For example:

  ```python
  from silk.profiling.profiler import silk_profile


  @silk_profile(name='View Blog Post')
  def post(request, post_id):
      p = Post.objects.get(pk=post_id)
      return render(request, 'post.html', {
          'post': p
      })
  ```

  Whenever a blog post is viewed we get an entry within the Silk UI:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/7.png" width="720px"/>

  Silk profiling not only provides execution time, but also collects SQL queries executed within the block in the same fashion as with requests:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/8.png" width="720px"/>



  The silk decorator can be applied to both functions and methods

  ```python
  from silk.profiling.profiler import silk_profile



  @silk_profile(name='View Blog Post')
  def post(request, post_id):
      p = Post.objects.get(pk=post_id)
      return render(request, 'post.html', {
          'post': p
      })



  class MyView(View):
      @silk_profile(name='View Blog Post')
      def get(self, request):
          p = Post.objects.get(pk=post_id)
          return render(request, 'post.html', {
              'post': p
          })
  ```



  Using a context manager means we can add additional context to the name which can be useful for
  narrowing down slowness to particular database records.

  ```python
  def post(request, post_id):
      with silk_profile(name='View Blog Post #%d' % self.pk):
          p = Post.objects.get(pk=post_id)
          return render(request, 'post.html', {
              'post': p
          })
  ```



  One of Silk's more interesting features is dynamic profiling. If for example we wanted to profile a function in a dependency to which we only have read-only access (e.g. system python libraries owned by root) we can add the following to `settings.py` to apply a decorator at runtime:

  ```python
  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'MyClass.bar'
  }]
  ```

  which is roughly equivalent to:

  ```python
  class MyClass:
      @silk_profile()
      def bar(self):
          pass
  ```

  The below summarizes the possibilities:

  ```python

  """
  Dynamic function decorator
  """

  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'foo'
  }]


  @silk_profile()
  def foo():
      pass

  """
  Dynamic method decorator
  """

  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'MyClass.bar'
  }]


  class MyClass:

      @silk_profile()
      def bar(self):
          pass

  """
  Dynamic code block profiling
  """

  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'foo',
      
      'start_line': 1,
      'end_line': 2,
      'name': 'Slow Foo'
  }]


  def foo():
      with silk_profile(name='Slow Foo'):
          print (1)
          print (2)
      print(3)
      print(4)
  ```

  Note that dynamic profiling behaves in a similar fashion to that of the python mock framework in that
  we modify the function in-place e.g:

  ```python
  """ my.module """
  from another.module import foo


  foo()

  ```

  ,we would profile `foo` by dynamically decorating `my.module.foo` as opposed to `another.module.foo`:

  ```python
  SILKY_DYNAMIC_PROFILING = [{
      'module': 'my.module',
      'function': 'foo'
  }]
  ```

  If we were to apply the dynamic profile to the functions source module `another.module.foo` **after**
  it has already been imported, no profiling would be triggered.




  Sometimes you may want to dynamically control when the profiler runs. You can write your own logic for when to enable the profiler. To do this add the following to your `settings.py`:

  This setting is mutually exclusive with SILKY_PYTHON_PROFILER and will be used over it if present. It will work with SILKY_DYNAMIC_PROFILING.

  ```python
  def my_custom_logic(request):
      return 'profile_requests' in request.session

  SILKY_PYTHON_PROFILER_FUNC = my_custom_logic # profile only session has recording enabled.
  ```

  You can also use a `lambda`.

  ```python

  SILKY_PYTHON_PROFILER_FUNC = lambda request: 'profile_requests' in request.session
  ```



  Silk currently generates two bits of code per request:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/9.png" width="720px"/>

  Both are intended for use in replaying the request. The curl command can be used to replay via command-line and the python code can be used within a Django unit test or simply as a standalone script.





  By default anybody can access the Silk user interface by heading to `/silk/`. To enable your Django
  auth backend place the following in `settings.py`:

  ```python
  SILKY_AUTHENTICATION = True  # User must login
  SILKY_AUTHORISATION = True  # User must have permissions
  ```

  If `SILKY_AUTHORISATION` is `True`, by default Silk will only authorise users with `is_staff` attribute set to `True`.

  You can customise this using the following in `settings.py`:

  ```python
  def my_custom_perms(user):
      return user.is_allowed_to_use_silk

  SILKY_PERMISSIONS = my_custom_perms
  ```

  You can also use a `lambda`.

  ```python
  SILKY_PERMISSIONS = lambda user: user.is_superuser
  ```



  By default, Silk will save down the request and response bodies for each request for future viewing
  no matter how large. If Silk is used in production under heavy volume with large bodies this can have
  a huge impact on space/time performance. This behaviour can be configured with the following options:

  ```python
  SILKY_MAX_REQUEST_BODY_SIZE = -1  # Silk takes anything <0 as no limit
  SILKY_MAX_RESPONSE_BODY_SIZE = 1024  # If response body>1024 bytes, ignore
  ```



  Sometimes it is useful to be able to see what effect Silk is having on the request/response time. To do this add
  the following to your `settings.py`:

  ```python
  SILKY_META = True
  ```

  Silk will then record how long it takes to save everything down to the database at the end of each
  request:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/meta.png"/>

  Note that in the above screenshot, this means that the request took 29ms (22ms from Django and 7ms from Silk)



  On high-load sites it may be helpful to only record a fraction of the requests that are made. To do this add the following to your `settings.py`:

  Note: This setting is mutually exclusive with SILKY_INTERCEPT_FUNC.

  ```python
  SILKY_INTERCEPT_PERCENT = 50 # log only 50% of requests
  ```



  On high-load sites it may also be helpful to write your own logic for when to intercept requests. To do this add the following to your `settings.py`:

  Note: This setting is mutually exclusive with SILKY_INTERCEPT_PERCENT.

  ```python
  def my_custom_logic(request):
      return 'record_requests' in request.session

  SILKY_INTERCEPT_FUNC = my_custom_logic # log only session has recording enabled.
  ```

  You can also use a `lambda`.

  ```python

  SILKY_INTERCEPT_FUNC = lambda request: 'record_requests' in request.session
  ```



  To make sure silky garbage collects old request/response data, a config var can be set to limit the number of request/response rows it stores.

  ```python
  SILKY_MAX_RECORDED_REQUESTS = 10**4
  ```

  The garbage collection is only run on a percentage of requests to reduce overhead.  It can be adjusted with this config:

  ```python
  SILKY_MAX_RECORDED_REQUESTS_CHECK_PERCENT = 10
  ```

  In case you want decouple silk's garbage collection from your webserver's request processing, set SILKY_MAX_RECORDED_REQUESTS_CHECK_PERCENT=0 and trigger it manually, e.g. in a cron job:

  ```bash
  python manage.py silk_request_garbage_collect
  ```



  To enable query analysis when supported by the dbms a config var can be set in order to execute queries with the analyze features.

  ```python
  SILKY_ANALYZE_QUERIES = True
  ```

  **Warning:** This setting may cause the database to execute the same query twice, depending on the backend. For instance, `EXPLAIN ANALYZE` in Postgres will [actually execute the query](https://www.postgresql.org/docs/current/sql-explain.html), which may result in unexpected data updates. Set this to True with caution.

  To pass additional params for profiling when supported by the dbms (e.g. VERBOSE, FORMAT JSON), you can do this in the following manner.

  ```python
  SILKY_EXPLAIN_FLAGS = {'format':'JSON', 'costs': True}
  ```




  By default, Silk is filtering values that contains the following keys (they are case insensitive)

  ```python
  SILKY_SENSITIVE_KEYS = {'username', 'api', 'token', 'key', 'secret', 'password', 'signature'}
  ```

  But sometimes, you might want to have your own sensitive keywords, then above configuration can be modified

  ```python
  SILKY_SENSITIVE_KEYS = {'custom-password'}
  ```




  A management command will wipe out all logged data:

  ```bash
  python manage.py silk_clear_request_log
  ```



  [![Jazzband](https://jazzband.co/static/img/jazzband.svg)](https://jazzband.co/)

  This is a [Jazzband](https://jazzband.co/) project. By contributing you agree to abide by the [Contributor Code of Conduct](https://jazzband.co/about/conduct) and follow the [guidelines](https://jazzband.co/about/guidelines).



  Silk features a project named `project` that can be used for `silk` development. It has the `silk` code symlinked so
  you can work on the sample `project` and on the `silk` package at the same time.

  In order to setup local development you should first install all the dependencies for the test `project`. From the
  root of the `project` directory:

  ```bash
  pip install -r requirements.txt
  ```

  You will also need to install `silk`'s dependencies. From the root of the git repository:

  ```bash
  pip install -e .
  ```

  At this point your virtual environment should have everything it needs to run both the sample `project` and
  `silk` successfully.

  Before running, you must set the `DB_ENGINE` and `DB_NAME` environment variables:

  ```bash
  export DB_ENGINE=sqlite3
  export DB_NAME=db.sqlite3
  ```

  For other combinations, check [`tox.ini`](./tox.ini).

  Now from the root of the sample `project` apply the migrations

  ```bash
  python manage.py migrate
  ```

  Now from the root of the sample `project` directory start the django server

  ```bash
  python manage.py runserver
  ```



  ```bash
  cd project
  python manage.py test
  ```

  Happy profiling!


pkgId: 65b5f41df250cd018a7c93b61c02b994ed6f4fca2095b87eb0edf74471833a7b
name: python-django-solo
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: Django Solo helps working with singletons
url: https://github.com/lazybird/django-solo/
rpm_license: Creative Commons Attribution 3.0 Unported
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ede7625b-cb08-4a7e-8233-7b97e2451be1
location_href: 00012013-python-django-solo/python-django-solo-2.0.0-1.src.rpm
checksum_type: sha256
description:
  <a href="https://pypi.org/project/django-solo/" alt="Current version on PyPi"><img src="https://img.shields.io/pypi/v/django-solo.svg" /></a>
      +---------------------------+
      |                           |
      |                           |
      |             \             | Django Solo helps working with singletons:
      |             /\            | database tables that only have one row.
      |           >=)'>           | Singletons are useful for things like global
      |             \/            | settings that you want to edit from the admin
      |             /             | instead of having them in Django settings.py.
      |                           |
      |                           |
      +---------------------------+


pkgId: 3ae617ce11c1ae7e11f2e83d2b4665544e39c4d77ef363025cde4a3d5d027dda
name: python-django-split-settings
arch: src
version: 1.2.0
epoch: 0
release: 1
url: https://django-split-settings.readthedocs.io
rpm_license: BSD-2-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-767a136e-e387-4815-84e6-c498561bea0a
location_href: 00012561-python-django-split-settings/python-django-split-settings-1.2.0-1.src.rpm
checksum_type: sha256
summary:
  Organize Django settings into multiple files and directories. Easily override and modify settings. Use wildcards and optional settings files.

description:
  [![wemake.services](https://img.shields.io/badge/%20-wemake.services-green.svg?label=%20&logo=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAALGPC%2FxhBQAAAAFzUkdCAK7OHOkAAAAbUExURQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP%2F%2F%2F5TvxDIAAAAIdFJOUwAjRA8xXANAL%2Bv0SAAAADNJREFUGNNjYCAIOJjRBdBFWMkVQeGzcHAwksJnAPPZGOGAASzPzAEHEGVsLExQwE7YswCb7AFZSF3bbAAAAABJRU5ErkJggg%3D%3D)](https://wemake.services)
  [![test](https://github.com/sobolevn/django-split-settings/workflows/test/badge.svg?branch=master&event=push)](https://github.com/sobolevn/django-split-settings/actions?query=workflow%3Atest)
  [![codecov](https://codecov.io/gh/sobolevn/django-split-settings/branch/master/graph/badge.svg)](https://codecov.io/gh/sobolevn/django-split-settings)
  [![Docs](https://readthedocs.org/projects/django-split-settings/badge/?version=latest)](http://django-split-settings.readthedocs.io/en/latest/?badge=latest)
  [![Python Version](https://img.shields.io/pypi/pyversions/django-split-settings.svg)](https://pypi.org/project/django-split-settings/)
  [![wemake-python-styleguide](https://img.shields.io/badge/style-wemake-000000.svg)](https://github.com/wemake-services/wemake-python-styleguide)
  Organize Django settings into multiple files and directories. Easily
  override and modify settings. Use wildcards in settings file paths
  and mark settings files as optional.
  Read [this blog post](https://sobolevn.me/2017/04/managing-djangos-settings)
  for more information.
  Also, check this [example project](https://github.com/wemake-services/wemake-django-template).

  While this package will most likely work with the most versions of `django`, we [officially support](https://github.com/sobolevn/django-split-settings/blob/master/.github/workflows/test.yml):
  - 2.2
  - 3.2
  - 4.0
  - 4.1
  This package has no dependencies itself.
  In case you need older `python` / `django` versions support,
  then consider using older versions of `django-split-settings`.

  ```bash
  pip install django-split-settings
  ```

  Replace your existing `settings.py` with a list of components that
  make up your Django settings. Preferably create a settings package
  that contains all the files.
  Here's a minimal example:
  ```python
  from split_settings.tools import optional, include
  include(
      'components/base.py',
      'components/database.py',
      optional('local_settings.py')
  )
  ```
  In the example, the files `base.py` and `database.py` are included
  in that order from the subdirectory called `components/`.
  `local_settings.py` in the same directory is included if it exists.
  **Note:** The local context is passed on to each file, so each
  following file can access and modify the settings declared in the
  previous files.
  We also made an in-depth [tutorial](https://sobolevn.me/2017/04/managing-djangos-settings).

  You can use wildcards in file paths:
  ```python
  include('components/my_app/*.py')
  ```
  Note that files are included in the order that `glob` returns them,
  probably in the same order as what `ls -U` would list them. The
  files are NOT in alphabetical order.
  You can modify common settings in environment settings simply importing them
  ```python

  from components.base import INSTALLED_APPS
  INSTALLED_APPS += (
    'raven.contrib.django.raven_compat',
  )
  ```

  Read the [CONTRIBUTING.md](https://github.com/sobolevn/django-split-settings/blob/master/CONTRIBUTING.md) file.

  See [CHANGELOG.md](https://github.com/sobolevn/django-split-settings/blob/master/CHANGELOG.md) file.


pkgId: 539a6275e71c297343a60e6ebe7b846efce346ee2d884740db5fa06d53f5ad2a
name: python-django-sql-explorer
arch: src
version: 3.1.1
epoch: 0
release: 1
summary: A pluggable app that allows users (admins) to execute SQL, view, and export the results.
url: https://github.com/groveco/django-sql-explorer
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-483e4e48-2453-4f92-a632-1a8bcfde6cc8
location_href: 00013013-python-django-sql-explorer/python-django-sql-explorer-3.1.1-1.src.rpm
checksum_type: sha256
description:
  SQL Explorer aims to make the flow of data between people fast,
  simple, and confusion-free. It is a Django-based application that you
  can add to an existing Django site, or use as a standalone business
  intelligence tool.
  Quickly write and share SQL queries in a simple, usable SQL editor,
  preview the results in the browser, share links, download CSV, JSON,
  or Excel files (and even expose queries as API endpoints, if desired),
  and keep the information flowing!
  Comes with support for multiple connections, to many different SQL
  database types, a schema explorer, query history (e.g. lightweight
  version control), a basic security model, in-browser pivot tables, and
  more.
  SQL Explorer values simplicity, intuitive use, unobtrusiveness,
  stability, and the principle of least surprise.
  SQL Explorer is inspired by any number of great query and
  reporting tools out there.
  The original idea came from Stack Exchange's `Data Explorer
  <http://data.stackexchange.com/stackoverflow/queries>`_, but also owes
  credit to similar projects like `Redash <http://redash.io/>`_ and
  `Blazer <https://github.com/ankane/blazer>`_.
  You can read the full documentation `here <https://django-sql-explorer.readthedocs.io/en/latest/>`_
  Sql Explorer is MIT licensed, and pull requests are welcome.
  **A view of a query**
  **Viewing all queries**
  **Quick access to DB schema info**
  **Snapshot query results to S3 & download as csv**


pkgId: 47f7e4933e5f4d18f727d53075d984c7af870a3eab6f0f1fb795250a22978be3
name: python-django-storages
arch: src
version: 1.13.2
epoch: 0
release: 1
summary: Support for many storage backends in Django
url: https://github.com/jschneier/django-storages
rpm_license: BSD-3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bac4cd7b-dfd6-4e53-b8db-8b4be5e1ced9
location_href: 00003490-python-django-storages/python-django-storages-1.13.2-1.src.rpm
checksum_type: sha256
description:
  Installing from PyPI is as easy as doing:
    pip install django-storages
  If you'd prefer to install from source (maybe there is a bugfix in master that
  hasn't been released yet) then the magic incantation you are looking for is:
    pip install -e 'git+https://github.com/jschneier/django-storages.git#egg=django-storages'
  Once that is done set ``DEFAULT_FILE_STORAGE`` to the backend of your choice.
  If, for example, you want to use the boto3 backend you would set:
    DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
  If you are using the ``FileSystemStorage`` as your storage management class in your models ``FileField`` fields, remove them
  and don't specify any storage parameter. That way, the ``DEFAULT_FILE_STORAGE`` class will be used by default in your field.
  For example, if you have a `photo` field defined as:
      photo = models.FileField(
          storage=FileSystemStorage(location=settings.MEDIA_ROOT),
          upload_to='photos',
      )
  Set it to just:
      photo = models.FileField(
          upload_to='photos',
      )
  There are also a number of settings available to control how each storage backend functions,
  please consult the documentation for a comprehensive list.


pkgId: fb65bc1682751db0acdf6fcaa706759e832f5b74d8df76fa5ca3fe61e09f0023
name: python-django-stubs
arch: src
version: 1.16.0
epoch: 0
release: 1
summary: Mypy stubs for Django
url: https://github.com/typeddjango/django-stubs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e63fded9-c7d6-4389-b6bc-5ddca1d90183
location_href: 00010219-python-django-stubs/python-django-stubs-1.16.0-1.src.rpm
checksum_type: sha256
description:
  <img src="http://mypy-lang.org/static/mypy_light.svg" alt="mypy logo" width="300px"/>



  [![Build status](https://github.com/typeddjango/django-stubs/workflows/test/badge.svg?branch=master&event=push)](https://github.com/typeddjango/django-stubs/actions?query=workflow%3Atest)
  [![Checked with mypy](http://www.mypy-lang.org/static/mypy_badge.svg)](http://mypy-lang.org/)
  [![Gitter](https://badges.gitter.im/mypy-django/Lobby.svg)](https://gitter.im/mypy-django/Lobby)
  [![StackOverflow](https://shields.io/badge/ask-stackoverflow-orange?logo=stackoverflow)](https://stackoverflow.com/questions/tagged/django-stubs)

  This package contains [type stubs](https://www.python.org/dev/peps/pep-0561/) and a custom mypy plugin to provide more precise static types and type inference for Django framework. Django uses some Python "magic" that makes having precise types for some code patterns problematic. This is why we need this project. The final goal is to be able to get precise types for most common patterns.



  ```bash
  pip install django-stubs[compatible-mypy]
  ```

  To make mypy aware of the plugin, you need to add

  ```ini
  [mypy]
  plugins =
      mypy_django_plugin.main

  [mypy.plugins.django-stubs]
  django_settings_module = "myproject.settings"
  ```

  in your `mypy.ini` or `setup.cfg` [file](https://mypy.readthedocs.io/en/latest/config_file.html).

  [pyproject.toml](https://mypy.readthedocs.io/en/stable/config_file.html#using-a-pyproject-toml-file) configurations are also supported:

  ```toml
  [tool.mypy]
  plugins = ["mypy_django_plugin.main"]

  [tool.django-stubs]
  django_settings_module = "myproject.settings"
  ```

  Two things happening here:

  1. We need to explicitly list our plugin to be loaded by `mypy`
  2. Our plugin also requires `django` settings module (what you put into `DJANGO_SETTINGS_MODULE` variable) to be specified

  This fully working [typed boilerplate](https://github.com/wemake-services/wemake-django-template) can serve you as an example.



  We rely on different `django` and `mypy` versions:

  | django-stubs | mypy version | django version | python version
  |--------------| ---- | ---- | ---- |
  | 1.16.0       | 1.1.x | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.15.0       | 1.0.x | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.14.0       | 0.990+ | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.13.0       | 0.980+ | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.12.0       | 0.931+ | 3.2.x or 4.0.x | ^3.7
  | 1.11.0       | 0.931+ | 3.2.x | ^3.7
  | 1.10.0       | 0.931+ | 3.2.x | ^3.7
  | 1.9.0        | 0.910 | 3.2.x | ^3.6
  | 1.8.0        | 0.812 | 3.1.x | ^3.6
  | 1.7.0        | 0.790 | 2.2.x \|\| 3.x | ^3.6
  | 1.6.0        | 0.780 | 2.2.x \|\| 3.x | ^3.6
  | 1.5.0        | 0.770 | 2.2.x \|\| 3.x | ^3.6
  | 1.4.0        | 0.760 | 2.2.x \|\| 3.x | ^3.6
  | 1.3.0        | 0.750 | 2.2.x \|\| 3.x | ^3.6
  | 1.2.0        | 0.730 | 2.2.x | ^3.6
  | 1.1.0        | 0.720 | 2.2.x | ^3.6
  | 0.12.x       | old semantic analyzer (<0.711), dmypy support | 2.1.x | ^3.6





  No, it is not. We are independent from Django at the moment.
  There's a [proposal](https://github.com/django/deps/pull/65) to merge our project into the Django itself.
  You can show your support by liking the PR.



  Yes, it is! This project does not affect your runtime at all.
  It only affects `mypy` type checking process.

  But, it does not make any sense to use this project without `mypy`.



  The current implementation uses Django's runtime to extract information about models, so it might crash if your installed apps or `models.py` are broken.

  In other words, if your `manage.py runserver` crashes, mypy will crash too.
  You can also run `mypy` with [`--tb`](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-show-traceback)
  option to get extra information about the error.



  You can get a `TypeError: 'type' object is not subscriptable`
  when you will try to use `QuerySet[MyModel]`, `Manager[MyModel]` or some other Django-based Generic types.

  This happens because these Django classes do not support [`__class_getitem__`](https://www.python.org/dev/peps/pep-0560/#class-getitem) magic method in runtime.

  1. You can go with our [`django_stubs_ext`](https://github.com/typeddjango/django-stubs/tree/master/django_stubs_ext) helper, that patches all the types we use as Generic in django.

     Install it:

     ```bash
     pip install django-stubs-ext  # as a production dependency
     ```

     And then place in your top-level settings:

     ```python
     import django_stubs_ext

     django_stubs_ext.monkeypatch()
     ```

     Note: This monkey patching approach will only work when using Python 3.7 and higher, when the `__class_getitem__` magic method was introduced.

     You can add extra types to patch with `django_stubs_ext.monkeypatch(extra_classes=[YourDesiredType])`

  2. You can use strings instead: `'QuerySet[MyModel]'` and `'Manager[MyModel]'`, this way it will work as a type for `mypy` and as a regular `str` in runtime.



  Django's built in [`HttpRequest`](https://docs.djangoproject.com/en/4.1/ref/request-response/#django.http.HttpRequest) has the attribute `user` that resolves to the type

  ```python
  Union[User, AnonymousUser]
  ```

  where `User` is the user model specified by the `AUTH_USER_MODEL` setting.

  If you want a `HttpRequest` that you can type-annotate with where you know that the user is authenticated you can subclass the normal `HttpRequest` class like so:

  ```python
  from django.http import HttpRequest
  from my_user_app.models import MyUser


  class AuthenticatedHttpRequest(HttpRequest):
      user: MyUser
  ```

  And then use `AuthenticatedHttpRequest` instead of the standard `HttpRequest` for when you know that the user is authenticated. For example in views using the `@login_required` decorator.



  If you are using `MyQuerySet.as_manager()`:

  Example:

  ```python
  from django.db import models

  class MyModelQuerySet(models.QuerySet):
      pass


  class MyModel(models.Model):
      bar = models.IntegerField()
      objects = MyModelQuerySet.as_manager()


  def use_my_model() -> int:
      foo = MyModel.objects.get(id=1) # Should now be `MyModel`
      return foo.xyz # Gives an error
  ```

  Or if you're using `Manager.from_queryset`:

  Example:

  ```python
  from django.db import models


  class MyModelQuerySet(models.QuerySet):
      pass


  MyModelManager = models.Manager.from_queryset(MyModelQuerySet)


  class MyModel(models.Model):
      bar = models.IntegerField()
      objects = MyModelManager()


  def use_my_model() -> int:
      foo = MyModel.objects.get(id=1) # Should now be `MyModel`
      return foo.xyz # Gives an error
  ```



  If you declare your custom managers without generics and override built-in
  methods you might see an error message about incompatible error messages,
  something like this:

  ```python
  from django.db import models

  class MyManager(model.Manager):
      def create(self, **kwargs) -> "MyModel":
          pass
  ```

  will cause this error message:

  > error: Return type "MyModel" of "create" incompatible with return type "_T" in supertype "BaseManager"

  This is happening because the `Manager` class is generic, but without
  specifying generics the built-in manager methods are expected to return the
  generic type of the base manager, which is any model. To fix this issue you
  should declare your manager with your model as the type variable:

  ```python
  class MyManager(models.Manager["MyModel"]):
      ...
  ```



  Django-stubs provides a special type, `django_stubs_ext.WithAnnotations[Model]`, which indicates that the `Model` has
  been annotated, meaning it allows getting/setting extra attributes on the model instance.

  Optionally, you can provide a `TypedDict` of these attributes,
  e.g. `WithAnnotations[MyModel, MyTypedDict]`, to specify which annotated attributes are present.

  Currently, the mypy plugin can recognize that specific names were passed to `QuerySet.annotate` and
  include them in the type, but does not record the types of these attributes.

  The knowledge of the specific annotated fields is not yet used in creating more specific types for `QuerySet`'s
  `values`, `values_list`, or `filter` methods, however knowledge that the model was annotated _is_ used to create a
  broader type result type for `values`/`values_list`, and to allow `filter`ing on any field.

  ```python
  from typing import TypedDict
  from django_stubs_ext import WithAnnotations
  from django.db import models
  from django.db.models.expressions import Value


  class MyModel(models.Model):
      username = models.CharField(max_length=100)


  def func(m: WithAnnotations[MyModel]) -> str:
      return m.asdf  # OK, since the model is annotated as allowing any attribute


  func(MyModel.objects.annotate(foo=Value("")).get(id=1))  # OK
  func(
      MyModel.objects.get(id=1)
  )  # Error, since this model will not allow access to any attribute


  class MyTypedDict(TypedDict):
      foo: str


  def func2(m: WithAnnotations[MyModel, MyTypedDict]) -> str:
      print(m.bar)  # Error, since field "bar" is not in MyModel or MyTypedDict.
      return m.foo  # OK, since we said field "foo" was allowed


  func(MyModel.objects.annotate(foo=Value("")).get(id=1))  # OK
  func(MyModel.objects.annotate(bar=Value("")).get(id=1))  # Error
  ```



  A limitation of making `QuerySet` generic is that you can not use
  it for `isinstance` checks.

  ```python
  from django.db.models.query import QuerySet

  def foo(obj: object) -> None:
      if isinstance(obj, QuerySet): # Error: Parameterized generics cannot be used with class or instance checks
          ...
  ```

  To get around with this issue without making `QuerySet` non-generic,
  Django-stubs provides `django_stubs_ext.QuerySetAny`, a non-generic
  variant of `QuerySet` suitable for runtime type checking:

  ```python
  from django_stubs_ext import QuerySetAny

  def foo(obj: object) -> None:
      if isinstance(obj, QuerySetAny):  # OK
          ...
  ```



  The lazy translation functions of Django (such as `gettext_lazy`) return a `Promise` instead of `str`. These two types [cannot be used interchangeably](https://github.com/typeddjango/django-stubs/pull/1139#issuecomment-1232167698). The return type of these functions was therefore [changed](https://github.com/typeddjango/django-stubs/pull/689) to reflect that.

  If you encounter this error in your own code, you can either cast the `Promise` to `str` (causing the translation to be evaluated), or use the `StrPromise` or `StrOrPromise` types from `django-stubs-ext` in type hints. Which solution to choose depends depends on the particular case. See [working with lazy translation objects](https://docs.djangoproject.com/en/4.1/topics/i18n/translation/#working-with-lazy-translation-objects) in the Django documentation for more information.

  If this is reported on Django code, please report an issue or open a pull request to fix the type hints.



  - [`awesome-python-typing`](https://github.com/typeddjango/awesome-python-typing) - Awesome list of all typing-related things in Python.
  - [`djangorestframework-stubs`](https://github.com/typeddjango/djangorestframework-stubs) - Stubs for Django REST Framework.
  - [`pytest-mypy-plugins`](https://github.com/typeddjango/pytest-mypy-plugins) - `pytest` plugin that we use for testing `mypy` stubs and plugins.
  - [`wemake-django-template`](https://github.com/wemake-services/wemake-django-template) - Create new typed Django projects in seconds.



  We have Gitter here: <https://gitter.im/mypy-django/Lobby>
  If you think you have more generic typing issue, please refer to <https://github.com/python/mypy> and their Gitter.



  This project is open source and community driven. As such we encourage contributions big and small. You can contribute by doing any of the following:

  1. Contribute code (e.g. improve stubs, add plugin capabilities, write tests etc) - to do so please follow the [contribution guide](./CONTRIBUTING.md).
  2. Assist in code reviews and discussions in issues.
  3. Identify bugs and issues and report these
  4. Ask and answer questions on [StackOverflow](https://stackoverflow.com/questions/tagged/django-stubs)

  You can always also reach out in gitter to discuss your contributions!


pkgId: cc4f335507d10be26d469db3b6e43f0539e4ee54e028548781ceaf8c8ea69bf2
name: python-django-stubs-ext
arch: src
version: 0.8.0
epoch: 0
release: 1
summary: Monkey-patching and extensions for django-stubs
url: https://github.com/typeddjango/django-stubs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fe0f837c-5556-400b-aa35-4f9aa5b68c11
location_href: 00010607-python-django-stubs-ext/python-django-stubs-ext-0.8.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.com/typeddjango/django-stubs.svg?branch=master)](https://travis-ci.com/typeddjango/django-stubs)
  [![Checked with mypy](http://www.mypy-lang.org/static/mypy_badge.svg)](http://mypy-lang.org/)
  [![Gitter](https://badges.gitter.im/mypy-django/Lobby.svg)](https://gitter.im/mypy-django/Lobby)


  This package contains extensions and monkey-patching functions for the [django-stubs](https://github.com/typeddjango/django-stubs) package. Certain features of django-stubs (i.e. generic django classes that don't define the `__class_getitem__` method) require runtime monkey-patching, which can't be done with type stubs. These extensions were split into a separate package so library consumers don't need `mypy` as a runtime dependency ([#526](https://github.com/typeddjango/django-stubs/pull/526#pullrequestreview-525798031)).



  ```bash
  pip install django-stubs-ext
  ```



  In your Django application, use the following code:

  ```py
  import django_stubs_ext

  django_stubs_ext.monkeypatch()
  ```

  This only needs to be called once, so the call to `monkeypatch` should be placed in your top-level settings.
  Real-life example [can be found here](https://github.com/wemake-services/wemake-django-template/blob/5bf1569e2710e11befc6991893f94419136d74bd/%7B%7Bcookiecutter.project_name%7D%7D/server/settings/__init__.py#L14-L19).



  Since django-stubs supports multiple Django versions, this package takes care to only monkey-patch the features needed by your django version, and decides which features to patch at runtime. This is completely safe, as (currently) we only add a `__class_getitem__` method that does nothing:

  ```py
  @classmethod
  def __class_getitem__(cls, *args, **kwargs):
      return cls
  ```



  For help with django-stubs, please view the main repository at <https://github.com/typeddjango/django-stubs>

  We have a Gitter chat here: <https://gitter.im/mypy-django/Lobby>
  If you think you have a more generic typing issue, please refer to <https://github.com/python/mypy> and their Gitter.



  The django-stubs-ext package is part of the [django-stubs](https://github.com/typeddjango/django-stubs) monorepo. If you would like to contribute, please view the django-stubs [contribution guide](https://github.com/typeddjango/django-stubs/blob/master/CONTRIBUTING.md).

  You can always also reach out in gitter to discuss your contributions!


pkgId: 53e7910f26d4ae752f49957f3aad023696485f36f3c0bb3733cbe538d1164889
name: python-django-tables2
arch: src
version: 2.5.3
epoch: 0
release: 1
summary: Table/data-grid framework for Django
url: https://github.com/jieter/django-tables2/
rpm_license: Simplified BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-75e0b147-a285-4856-a655-0e97f119305d
location_href: 00003496-python-django-tables2/python-django-tables2-2.5.3-1.src.rpm
checksum_type: sha256
description:
  [![Latest PyPI version](https://badge.fury.io/py/django-tables2.svg)](https://pypi.python.org/pypi/django-tables2)
  [![Any color you like](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/ambv/black)

  django-tables2 simplifies the task of turning sets of data into HTML tables. It
  has native support for pagination and sorting. It does for HTML tables what
  `django.forms` does for HTML forms. e.g.

  - Available on pypi as [django-tables2](https://pypi.python.org/pypi/django-tables2)
  - Tested against currently supported versions of Django
    [and supported python 3 versions Django supports](https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django).
  - [Documentation on readthedocs.org](https://django-tables2.readthedocs.io/en/latest/)
  - [Bug tracker](http://github.com/jieter/django-tables2/issues)

  Features:

  - Any iterable can be a data-source, but special support for Django `QuerySets` is included.
  - The builtin UI does not rely on JavaScript.
  - Support for automatic table generation based on a Django model.
  - Supports custom column functionality via subclassing.
  - Pagination.
  - Column based table sorting.
  - Template tag to enable trivial rendering to HTML.
  - Generic view mixin.

  ![An example table rendered using django-tables2](https://cdn.rawgit.com/jieter/django-tables2/master/docs/img/example.png)

  ![An example table rendered using django-tables2 and bootstrap theme](https://cdn.rawgit.com/jieter/django-tables2/master/docs/img/bootstrap.png)

  ![An example table rendered using django-tables2 and semantic-ui theme](
  https://cdn.rawgit.com/jieter/django-tables2/master/docs/img/semantic.png)



  Start by adding `django_tables2` to your `INSTALLED_APPS` setting like this:

  ```python
  INSTALLED_APPS = (
      ...,
      "django_tables2",
  )
  ```

  Creating a table for a model `Simple` is as simple as:

  ```python
  import django_tables2 as tables

  class SimpleTable(tables.Table):
      class Meta:
          model = Simple
  ```
  This would then be used in a view:

  ```python
  class TableView(tables.SingleTableView):
      table_class = SimpleTable
      queryset = Simple.objects.all()
      template_name = "simple_list.html"
  ```
  And finally in the template:

  ```
  {% load django_tables2 %}
  {% render_table table %}
  ```

  This example shows one of the simplest cases, but django-tables2 can do a lot more!
  Check out the [documentation](https://django-tables2.readthedocs.io/en/latest/) for more details.


pkgId: 6615dd28edf1796a7f44e6e059428909c02cd60e5ec635df549cd4926b02a42b
name: python-django-taggit
arch: src
version: 3.1.0
epoch: 0
release: 1
summary: django-taggit is a reusable Django application for simple tagging.
url: https://github.com/jazzband/django-taggit
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2461dcdc-3027-4d85-bbb4-e68b765f38e5
location_href: 00003498-python-django-taggit/python-django-taggit-3.1.0-1.src.rpm
checksum_type: sha256
description:
  This is a `Jazzband <https://jazzband.co>`_ project. By contributing you agree
  to abide by the `Contributor Code of Conduct
  <https://jazzband.co/about/conduct>`_ and follow the `guidelines
  <https://jazzband.co/about/guidelines>`_.
  ``django-taggit`` a simpler approach to tagging with Django.  Add ``"taggit"`` to your
  ``INSTALLED_APPS`` then just add a TaggableManager to your model and go:
      from django.db import models
      from taggit.managers import TaggableManager
      class Food(models.Model):
          
          tags = TaggableManager()
  Then you can use the API like so:
      >>> apple = Food.objects.create(name="apple")
      >>> apple.tags.add("red", "green", "delicious")
      >>> apple.tags.all()
      [<Tag: red>, <Tag: green>, <Tag: delicious>]
      >>> apple.tags.remove("green")
      >>> apple.tags.all()
      [<Tag: red>, <Tag: delicious>]
      >>> Food.objects.filter(tags__name__in=["red"])
      [<Food: apple>, <Food: cherry>]
  Tags will show up for you automatically in forms and the admin.
  ``django-taggit`` requires Django 3.2 or greater.
  For more info check out the `documentation
  <https://django-taggit.readthedocs.io/>`_. And for questions about usage or
  development you can create an issue on Github (if your question is about
  usage please add the `question` tag).


pkgId: 731ad55b2eea0efdec0afa469e4605d712d1bb6b2beaaae5ce22fc21ba832e8f
name: python-django-taggit-serializer
arch: src
version: 0.1.7
epoch: 0
release: 1
summary: The Django Taggit serializer for tDjango REST Framework
url: https://github.com/glemmaPaul/django-taggit-serializer
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-61b0f1ba-0f4e-4e63-b6e9-8f98e3200658
location_href: 00003499-python-django-taggit-serializer/python-django-taggit-serializer-0.1.7-1.src.rpm
checksum_type: sha256
description:
  The Django Taggit Serializer for the DjangoREST Framework developers. Installation can be found on https://github.com/glemmaPaul/django-taggit-serializer


pkgId: ef9088112be85a3bafcfcf1311a16c2113bfc4b366ea3a96755fd46295c304fa
name: python-django-test-migrations
arch: src
version: 1.2.0
epoch: 0
release: 1
summary: Test django schema and data migrations, including ordering
url: https://github.com/wemake-services/django-test-migrations
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ae9e0d62-a3cb-41a4-930c-bedb8fdb93a3
location_href: 00013005-python-django-test-migrations/python-django-test-migrations-1.2.0-1.src.rpm
checksum_type: sha256
description:
  [![wemake.services](https://img.shields.io/badge/%20-wemake.services-green.svg?label=%20&logo=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAALGPC%2FxhBQAAAAFzUkdCAK7OHOkAAAAbUExURQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP%2F%2F%2F5TvxDIAAAAIdFJOUwAjRA8xXANAL%2Bv0SAAAADNJREFUGNNjYCAIOJjRBdBFWMkVQeGzcHAwksJnAPPZGOGAASzPzAEHEGVsLExQwE7YswCb7AFZSF3bbAAAAABJRU5ErkJggg%3D%3D)](https://wemake.services)
  [![Build status](https://github.com/wemake-services/django-test-migrations/workflows/test/badge.svg?branch=master&event=push)](https://github.com/wemake-services/django-test-migrations/actions?query=workflow%3Atest)
  [![codecov](https://codecov.io/gh/wemake-services/django-test-migrations/branch/master/graph/badge.svg)](https://codecov.io/gh/wemake-services/django-test-migrations)
  [![Python Version](https://img.shields.io/pypi/pyversions/django-test-migrations.svg)](https://pypi.org/project/django-test-migrations/)
  ![PyPI - Django Version](https://img.shields.io/pypi/djversions/django-test-migrations)
  [![wemake-python-styleguide](https://img.shields.io/badge/style-wemake-000000.svg)](https://github.com/wemake-services/wemake-python-styleguide)




  - Allows to test `django` schema and data migrations
  - Allows to test both forward and rollback migrations
  - Allows to test the migrations order
  - Allows to test migration names
  - Allows to test database configuration
  - Fully typed with annotations and checked with `mypy`, [PEP561 compatible](https://www.python.org/dev/peps/pep-0561/)
  - Easy to start: has lots of docs, tests, and tutorials

  Read the [announcing post](https://sobolevn.me/2019/10/testing-django-migrations).
  See real-world [usage example](https://github.com/wemake-services/wemake-django-template).




  ```bash
  pip install django-test-migrations
  ```

  We support several `django` versions:

  - `1.11`
  - `2.2`
  - `3.1`
  - `3.2`
  - `4.0`

  Other versions might work too, but they are not officially supported.




  Testing migrations is not a frequent thing in `django` land.
  But, sometimes it is totally required. When?

  When we do complex schema or data changes
  and what to be sure that existing data won't be corrupted.
  We might also want to be sure that all migrations can be safely rolled back.
  And as a final touch we want to be sure that migrations
  are in the correct order and have correct dependencies.



  To test all migrations we have a [`Migrator`](https://github.com/wemake-services/django-test-migrations/blob/master/django_test_migrations/migrator.py) class.

  It has three methods to work with:

  - `.apply_initial_migration()` which takes app and migration names to generate
    a state before the actual migration happens. It creates the `before state`
    by applying all migrations up to and including the ones passed as an argument.

  - `.apply_tested_migration()` which takes app and migration names to perform the
    actual migration

  - `.reset()` to clean everything up after we are done with testing

  So, here's an example:

  ```python
  from django_test_migrations.migrator import Migrator

  migrator = Migrator(database='default')








  old_state = migrator.apply_initial_migration(('main_app', '0001_initial'))
  SomeItem = old_state.apps.get_model('main_app', 'SomeItem')


  SomeItem.objects.create(string_field='a')
  assert len(SomeItem._meta.get_fields()) == 2  # id + string_field


  new_state = migrator.apply_tested_migration(
      ('main_app', '0002_someitem_is_clean'),
  )
  SomeItem = new_state.apps.get_model('main_app', 'SomeItem')


  assert SomeItem.objects.filter(is_clean=True).count() == 0
  assert len(SomeItem._meta.get_fields()) == 3  # id + string_field + is_clean


  migrator.reset()
  ```

  That was an example of a forward migration.



  The thing is that you can also test backward migrations.
  Nothing really changes except migration names that you pass and your logic:

  ```python
  migrator = Migrator()


  old_state = migrator.apply_initial_migration(
      ('main_app', '0002_someitem_is_clean'),
  )
  SomeItem = old_state.apps.get_model('main_app', 'SomeItem')





  new_state = migrator.apply_tested_migration(('main_app', '0001_initial'))





  migrator.reset()
  ```



  Sometimes we also want to be sure that our migrations are in the correct order.
  And all our `dependecies = [...]` are correct.

  To achieve that we have [`plan.py`](https://github.com/wemake-services/django-test-migrations/blob/master/django_test_migrations/plan.py) module.

  That's how it can be used:

  ```python
  from django_test_migrations.plan import all_migrations, nodes_to_tuples

  main_migrations = all_migrations('default', ['main_app', 'other_app'])
  assert nodes_to_tuples(main_migrations) == [
      ('main_app', '0001_initial'),
      ('main_app', '0002_someitem_is_clean'),
      ('other_app', '0001_initial'),
      ('main_app', '0003_update_is_clean'),
      ('main_app', '0004_auto_20191119_2125'),
      ('other_app', '0002_auto_20191120_2230'),
  ]
  ```

  This way you can be sure that migrations
  and apps that depend on each other will be executed in the correct order.




  We support several test frameworks as first-class citizens.
  That's a testing tool after all!

  Note that the Django `post_migrate` signal's receiver list is cleared at
  the start of tests and restored afterwards. If you need to test your
  own `post_migrate` signals then attach/remove them during a test.



  We ship `django-test-migrations` with a `pytest` plugin
  that provides two convinient fixtures:

  - `migrator_factory` that gives you an opportunity
    to create `Migrator` classes for any database
  - `migrator` instance for the `'default'` database

  That's how it can be used:

  ```python
  import pytest

  @pytest.mark.django_db()
  def test_pytest_plugin_initial(migrator):
      """Ensures that the initial migration works."""
      old_state = migrator.apply_initial_migration(('main_app', None))

      with pytest.raises(LookupError):
          
          old_state.apps.get_model('main_app', 'SomeItem')

      new_state = migrator.apply_tested_migration(('main_app', '0001_initial'))
      
      SomeItem = new_state.apps.get_model('main_app', 'SomeItem')
      assert SomeItem.objects.filter(string_field='').count() == 0
  ```



  We also ship an integration with the built-in `unittest` framework.

  Here's how it can be used:

  ```python
  from django_test_migrations.contrib.unittest_case import MigratorTestCase

  class TestDirectMigration(MigratorTestCase):
      """This class is used to test direct migrations."""

      migrate_from = ('main_app', '0002_someitem_is_clean')
      migrate_to = ('main_app', '0003_update_is_clean')

      def prepare(self):
          """Prepare some data before the migration."""
          SomeItem = self.old_state.apps.get_model('main_app', 'SomeItem')
          SomeItem.objects.create(string_field='a')
          SomeItem.objects.create(string_field='a b')

      def test_migration_main0003(self):
          """Run the test itself."""
          SomeItem = self.new_state.apps.get_model('main_app', 'SomeItem')

          assert SomeItem.objects.count() == 2
          assert SomeItem.objects.filter(is_clean=True).count() == 1
  ```



  In CI systems it is important to get instant feedback. Running tests that
  apply database migration can slow down tests execution, so it is often a good
  idea to run standard, fast, regular unit tests without migrations in parallel
  with slower migrations tests.



  `django_test_migrations` adds `migration_test` marker to each test using
  `migrator_factory` or `migrator` fixture.
  To run only migrations test, use `-m` option:

  ```bash
  pytest -m migration_test  # runs only migraion tests
  pytest -m "not migration_test"  # runs all except migraion tests
  ```



  `django_test_migrations` adds `migration_test`
  [tag](https://docs.djangoproject.com/en/3.0/topics/testing/tools/#tagging-tests)
  to every `MigratorTestCase` subclass.
  To run only migrations tests, use `--tag` option:

  ```bash
  python mange.py test --tag=migration_test  # runs only migraion tests
  python mange.py test --exclude-tag=migration_test  # runs all except migraion tests
  ```




  `django_test_migrations` comes with 2 groups of Django's checks for:

  + detecting migrations scripts automatically generated names
  + validating some subset of database settings



  `django` generates migration names for you when you run `makemigrations`.
  And these names are bad ([read more](https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/) about why it is bad)!
  Just look at this: `0004_auto_20191119_2125.py`

  What does this migration do? What changes does it have?

  One can also pass `--name` attribute when creating migrations, but it is easy to forget.

  We offer an automated solution: `django` check
  that produces an error for each badly named migration.

  Add our check into your `INSTALLED_APPS`:

  ```python
  INSTALLED_APPS = [
      

      
      'django_test_migrations.contrib.django_checks.AutoNames',
  ]
  ```

  And then in your CI run:

  ```bash
  python manage.py check --deploy
  ```

  This way you will be safe from wrong names in your migrations.

  Do you have a migrations that cannot be renamed? Add them to the ignore list:

  ```python


  DTM_IGNORED_MIGRATIONS = {
      ('main_app', '0004_auto_20191119_2125'),
      ('dependency_app', '0001_auto_20201110_2100'),
  }
  ```

  And we won't complain about them.

  Or you can completely ignore entire app:

  ```python


  DTM_IGNORED_MIGRATIONS = {
      ('dependency_app', '*'),
      ('another_dependency_app', '*'),
  }
  ```



  Add our check to `INSTALLED_APPS`:

  ```python
  INSTALLED_APPS = [
      

      
      'django_test_migrations.contrib.django_checks.DatabaseConfiguration',
  ]
  ```

  Then just run `check` management command in your CI like listed in section
  above.




  You might also like:

  - [django-migration-linter](https://github.com/3YOURMIND/django-migration-linter) - Detect backward incompatible migrations for your django project.
  - [wemake-django-template](https://github.com/wemake-services/wemake-django-template/) - Bleeding edge django template focused on code quality and security with both `django-test-migrations` and `django-migration-linter` on board.




  This project is based on work of other awesome people:

  - [@asfaltboy](https://gist.github.com/asfaltboy/b3e6f9b5d95af8ba2cc46f2ba6eae5e2)
  - [@blueyed](https://gist.github.com/blueyed/4fb0a807104551f103e6)
  - [@fernandogrd](https://gist.github.com/blueyed/4fb0a807104551f103e6#gistcomment-1546191)
  - [@adamchainz](https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/)




  MIT.


