# packages

pkgId: 26142c40dc8482e381e17e482b93019a863c8eb4ed69cf68f542608722ca58fe
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-c27b98f7-e6ed-4217-8507-d96d2bef090c
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: fec45aa9536e3865cdb7c371a8d65f4d37ccb4c420f30e5030993c1ecff781d4
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-11ed511c-3b11-472c-bf4d-23c1eda36033
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: acd024a4b67eb1e714b002620ba8b8e9faaf391c13c0ddc27a4c5a6314930130
name: python-django-revproxy
arch: src
version: 0.10.0
epoch: 0
release: 1
summary: Yet another Django reverse proxy application.
url: https://github.com/TracyWebTech/django-revproxy
rpm_license: MPL v2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-45ca3448-c6c7-48cb-82d9-f820672b9540
location_href: 00014193-python-django-revproxy/python-django-revproxy-0.10.0-1.src.rpm
checksum_type: sha256
description:
  A simple reverse proxy using Django. It allows to use Django as a
  reverse Proxy to HTTP requests. It also allows to use Django as an
  authentication Proxy.
  Documentation available at http://django-revproxy.readthedocs.org/


pkgId: 2e9761b689ebebe8e8bd1585d92c0bf7517d5269d54219f5616192f388ea0c3a
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-1f8d3c90-a83a-4f99-9edc-7381d49b832c
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: 6179cf5a674abb2a5a1da9beb3dd94b937b1ac559044890f5f2699bc58eec4b3
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-8127775e-06e2-412c-aeab-abf77f52acd7
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: e2a9a35adc64d64739984fd5ed35a0875e1179344db1ba10232544e02474a118
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-9c7c172e-f2a7-4ff6-a60c-cbdccd47a748
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: fcbe22bd8fb391f65d4d3c2613c097aeff000ba4142c66cb503bb2e193e20cb9
name: python-django-sequences
arch: src
version: 2.7
epoch: 0
release: 1
summary: Generate gapless sequences of integer values.
url: https://github.com/aaugustin/django-sequences
rpm_license: BSD-3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f6791bf5-69b4-4d9b-81a8-60e0b8a1f9cb
location_href: 00013872-python-django-sequences/python-django-sequences-2.7-1.src.rpm
checksum_type: sha256
description:
  * `Getting started`_
  * `Database support`_
  * `Multiple databases`_
  * `Isolation levels`_
  * `Contributing`_
  * `Releasing`_
  * `Changelog`_


pkgId: d19dad3f20a4b5707552d0e0eca254be0966e84a2007b7f900217f1f671b8c78
name: python-django-session-security
arch: src
version: 2.6.7
epoch: 0
release: 1
summary: Client and server side session timeout with warnings
url: https://github.com/yourlabs/django-session-security
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f601d7e6-7487-4342-8e84-55bb4e7adfd1
location_href: 00013827-python-django-session-security/python-django-session-security-2.6.7-1.src.rpm
checksum_type: sha256
description:
  Or "Why does this app even exist" ? Here are the reasons:
  - if the user session expires before the user is done reading a page: he will
    have to login again.
  - if the user session expires before the user is done filling a form: his work
    will be lost, and he will have to login again, and probably yell at you, dear
    django dev ... at least I know I would !
  This app allows to short circuit those limitations in session expiry.


pkgId: 245bf39013d2fe63d74c237ee118b693e8253074718f5fbe8ee994670902fef1
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-8a5a8bab-b5aa-4326-8f02-43d09007b882
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: 4e68b6e00e3b9f60a3946b7079f8c574c128fd1f80eda109781965f9824a0bae
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-f835e52e-444a-474d-8a91-e4911cb66ef2
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: 92a3baa1bd2ed611deeb46fb2fe2b4a258d16630e9a07e912fb80e398ac76256
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-cc278cf8-523f-44bd-b142-382fa261083e
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: 86e5a661c5e7668183c1c33c5add016a4047a18b68de6d9ce022676baa300f95
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-42bfe24e-b9f2-405f-9627-7cfe71c64e0e
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: 5e61a5eb64a814632e05b678de1b554a3c2cdda7309ac053ba53816a4ed916b0
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-8e1b649d-bdb1-410e-bf28-150f5d141c63
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: 0e81a8ea0a1a8f3d51be17b09566656b7964b79b0655593b7a80c07af3015087
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-cf8522f7-2e3a-419a-922e-17f7759584c4
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: 7ba5f3e78a1e29eec133a0a905e4c871e9596bd3e0e1656f77dae2c81bda7b5a
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-bd1d8133-d5e7-40e6-a7a8-aa369a9b8176
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: 64d84144ab9af45e4836432e7dad93335511b637cb5860900999c0576555ae49
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-765c4863-f91c-4851-9ece-3ed3e3d819a5
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: 03156bfa872cf87d0e902ab00dcacc949844f1d7a9337f7ba817f7fcf5a6b054
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-ddac6c9b-efb5-40d5-a18f-92babd52c326
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: 8b03e30d287f76cd7e51314c93ff9cf33c6e387fb7d17efb38bcca2fc6f3e6d7
name: python-django-tenants
arch: src
version: 3.4.8
epoch: 0
release: 1
summary: Tenant support for Django using PostgreSQL schemas.
url: https://github.com/django-tenants/django-tenants
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ccc404b7-65c9-4111-bb5d-e3dcfc22dd4c
location_href: 00013623-python-django-tenants/python-django-tenants-3.4.8-1.src.rpm
checksum_type: sha256
description:
  This application enables `django`_ powered websites to have multiple
  tenants via `PostgreSQL schemas`_. A vital feature for every
  Software-as-a-Service (SaaS) website.
      Read the full documentation here: `django-tenants.readthedocs.org`_
  Django provides currently no simple way to support multiple tenants
  using the same project instance, even when only the data is different.
  Because we don’t want you running many copies of your project, you’ll be
  able to have:
  -  Multiple customers running on the same instance
  -  Shared and Tenant-Specific data
  -  Tenant View-Routing


pkgId: 5232700f4bbe3e9ae984277e65576ff1b88e97283058f16124e9350336a1a980
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-4d96d379-a8b3-4004-8f83-0b628d63a36c
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.


pkgId: 1f9f980c88d8e40d8a08ff2fcf3f835513aec62e395283a32667f2606f1ebd03
name: python-django-test-without-migrations
arch: src
version: 0.6
epoch: 0
release: 1
summary: Disable migrations when running your Django tests.
url: http://github.com/henriquebastos/django-test-without-migrations/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b914f5c3-722f-4373-8e81-1763a7281b20
location_href: 00012295-python-django-test-without-migrations/python-django-test-without-migrations-0.6-1.src.rpm
checksum_type: sha256
description:
  *Test Without Migrations* is a `manage.py test` command extension.
  The new Django 1.7 and 1.8 migration backend demands that you create a migration every time you change a model.
  This can be inconvenient when you're just trying to explore your models code.
  In older Django versions, with `South` we could use the `SOUTH_TEST_MIGRATIONS` settings to tell Django to simply create all model tables without running migrations.
  This app adds this capability to Django by extending the `manage.py test` command with a `--nomigrations` option.


pkgId: 3b818ab1c30243b43e12ccd308507a4acf481da7b165069fb897876f9792c25d
name: python-django-test-without-migrations-help
arch: noarch
version: 0.6
epoch: 0
release: 1
summary: Development documents and examples for django-test-without-migrations
url: http://github.com/henriquebastos/django-test-without-migrations/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b914f5c3-722f-4373-8e81-1763a7281b20
rpm_sourcerpm: python-django-test-without-migrations-0.6-1.src.rpm
checksum_type: sha256
description:
  *Test Without Migrations* is a `manage.py test` command extension.
  The new Django 1.7 and 1.8 migration backend demands that you create a migration every time you change a model.
  This can be inconvenient when you're just trying to explore your models code.
  In older Django versions, with `South` we could use the `SOUTH_TEST_MIGRATIONS` settings to tell Django to simply create all model tables without running migrations.
  This app adds this capability to Django by extending the `manage.py test` command with a `--nomigrations` option.

location_href:
  00012295-python-django-test-without-migrations/python-django-test-without-migrations-help-0.6-1.noarch.rpm


pkgId: 5773925062ea0dbbab441692c4c34f93441117affb750f579b09b40e30cb47a1
name: python-django-threadedcomments
arch: src
version: 2.0
epoch: 0
release: 1
summary: A simple yet flexible threaded commenting system.
url: https://github.com/HonzaKral/django-threadedcomments
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9c9aa784-1090-4d82-b377-45486a67e116
location_href: 00003501-python-django-threadedcomments/python-django-threadedcomments-2.0-1.src.rpm
checksum_type: sha256
description:
  *threadedcomments* is a Django application which allows for the simple creation of a threaded commenting system.
  Commenters can reply both to the original item, and reply to other comments as well.
  The application is built on top of django_comments_,
  which allows it to be easily extended by other modules.


pkgId: 0f41d6cf2e918fc92008235f2b6ba84811ac0b32f1ad2575acb7f6ca9da57cb1
name: python-django-tinymce
arch: src
version: 3.6.1
epoch: 0
release: 1
summary: A Django application that contains a widget to render a form field as a TinyMCE editor.
url: https://github.com/jazzband/django-tinymce
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9b1c5d61-4813-4b4a-82fa-040d59a78f16
location_href: 00011606-python-django-tinymce/python-django-tinymce-3.6.1-1.src.rpm
checksum_type: sha256
description:
  **django-tinymce** is a Django application that contains a widget to render a form field as a TinyMCE editor.


pkgId: 3defdab45830e4b06b280e892d9179f076748a6a8c879bffc21c6b490f090b0d
name: python-django-treebeard
arch: src
version: 4.6.1
epoch: 0
release: 1
summary: Efficient tree implementations for Django
url: https://github.com/django-treebeard/django-treebeard/
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-8ef80b10-400f-4f00-ae10-af7c89590c24
location_href: 00010614-python-django-treebeard/python-django-treebeard-4.6.1-1.src.rpm
checksum_type: sha256
description:
  **django-treebeard** is a library that implements efficient tree
  implementations for the Django Web Framework 2.2 and later.

  It is written by Gustavo Picón and licensed under the Apache License
  2.0.



  [![Documentation Status](https://readthedocs.org/projects/django-treebeard/badge/?version=latest)](https://django-treebeard.readthedocs.io/en/latest/?badge=latest)
  [![Tests](https://github.com/django-treebeard/django-treebeard/workflows/Tests/badge.svg)]()
  [![App Veyor](https://ci.appveyor.com/api/projects/status/mwbf062v68lhw05c?svg=true)](https://ci.appveyor.com/project/mvantellingen/django-treebeard)
  [![PyPI](https://img.shields.io/pypi/pyversions/django-treebeard.svg)]()
  [![PyPI version](https://img.shields.io/pypi/v/django-treebeard.svg)](https://pypi.org/project/django-treebeard/)




  django-treebeard is:

  -   **Flexible**: Includes 3 different tree implementations with the
      same API:
      1.  Adjacency List
      2.  Materialized Path
      3.  Nested Sets
  -   **Fast**: Optimized non-naive tree operations
  -   **Easy**: Uses Django Model Inheritance with abstract classes to
      define your own models.
  -   **Clean**: Testable and well tested code base. Code/branch test
      coverage is above 96%.

  You can find the documentation in

  > <http://django-treebeard.readthedocs.io/en/latest/>



  **django-treebeard** officially supports

  -   Django 3.2, 4.0, 4.1
  -   Python 3.8 - 3.11
  -   PostgreSQL, MySQL, MSSQL, SQLite database back-ends.


pkgId: 05a1cb8a36d058483bd89d370f64604080acbbdac880edc904439b5f2fb4d855
name: python-django-user-tasks
arch: src
version: 3.0.0
epoch: 0
release: 1
summary: Management of user-triggered asynchronous tasks in Django projects
url: https://github.com/edx/django-user-tasks
rpm_license: Apache Software License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-cabaf6c6-7d3e-4048-8dfd-41f8f2bc6dc1
location_href: 00013993-python-django-user-tasks/python-django-user-tasks-3.0.0-1.src.rpm
checksum_type: sha256
description:
  django-user-tasks is a reusable Django application for managing user-triggered
  asynchronous tasks.  It provides a status page for each such task, which
  includes a meaningful progress indicator if the task is currently being
  executed and provides any appropriate text and/or links for output once the
  task is complete.
  In Open edX, such tasks include operations such as exporting or importing a
  course, sending an email to all the students in a course, uploading a video,
  and other tasks which often take too long to perform during a single web
  request (as outlined in `OEP-3`_).  However, this has been written with the
  intention of being useful in a variety of Django projects outside the Open edX
  platform as well.
  Note that this library was created as a consolidation of lessons learned from
  implementing such tasks in various parts of the Open edX code base.  They
  don't yet all use this library, but the plan is to over time refactor many of
  them to do so.


pkgId: 896160e406025959df4d7077b0d5a9a88c19c4a28fce12706226454ce364ae73
name: python-django-uuslug
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: A Django slugify application that also handles Unicode
url: https://github.com/un33k/django-uuslug
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e263084b-9ca0-4d53-b492-97ed52b4d57e
location_href: 00003503-python-django-uuslug/python-django-uuslug-2.0.0-1.src.rpm
checksum_type: sha256
description:
  **A Django slugify application that guarantees `Uniqueness` and handles `Unicode`**

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



  In short: UUSlug == (`U`nique + `U`nicode) Slug



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



  ```python

   

   from uuslug import slugify

   txt = "This is a test ---"
   r = slugify(txt)
   self.assertEqual(r, "this-is-a-test")

   txt = "___This is a test ---"
   r = slugify(txt)
   self.assertEqual(r, "this-is-a-test")

   txt = "___This is a test___"
   r = slugify(txt)
   self.assertEqual(r, "this-is-a-test")

   txt = "This -- is a ## test ---"
   r = slugify(txt)
   self.assertEqual(r, "this-is-a-test")

   txt = '影師嗎'
   r = slugify(txt)
   self.assertEqual(r, "ying-shi-ma")

   txt = 'C\'est déjà l\'été.'
   r = slugify(txt)
   self.assertEqual(r, "c-est-deja-l-ete")

   txt = 'Nín hǎo. Wǒ shì zhōng guó rén'
   r = slugify(txt)
   self.assertEqual(r, "nin-hao-wo-shi-zhong-guo-ren")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt)
   self.assertEqual(r, "jaja-lol-mememeoo-a")

   txt = 'Компьютер'
   r = slugify(txt)
   self.assertEqual(r, "kompiuter")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=9)
   self.assertEqual(r, "jaja-lol")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=15)
   self.assertEqual(r, "jaja-lol-mememe")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=50)
   self.assertEqual(r, "jaja-lol-mememeoo-a")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=15, word_boundary=True)
   self.assertEqual(r, "jaja-lol-a")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=17, word_boundary=True)
   self.assertEqual(r, "jaja-lol-mememeoo")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=18, word_boundary=True)
   self.assertEqual(r, "jaja-lol-mememeoo")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=19, word_boundary=True)
   self.assertEqual(r, "jaja-lol-mememeoo-a")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=20, word_boundary=True, separator=".")
   self.assertEqual(r, "jaja.lol.mememeoo.a")

   txt = 'jaja---lol-méméméoo--a'
   r = slugify(txt, max_length=20, word_boundary=True, separator="ZZZZZZ")
   self.assertEqual(r, "jajaZZZZZZlolZZZZZZmememeooZZZZZZa")

   txt = 'one two three four five'
   r = slugify(txt, max_length=13, word_boundary=True, save_order=True)
   self.assertEqual(r, "one-two-three")

   txt = 'one two three four five'
   r = slugify(txt, max_length=13, word_boundary=True, save_order=False)
   self.assertEqual(r, "one-two-three")

   txt = 'one two three four five'
   r = slugify(txt, max_length=12, word_boundary=True, save_order=False)
   self.assertEqual(r, "one-two-four")

   txt = 'one two three four five'
   r = slugify(txt, max_length=12, word_boundary=True, save_order=True)
   self.assertEqual(r, "one-two")

   txt = 'this has a stopword'
   r = slugify(txt, stopwords=['stopword'])
   self.assertEqual(r, 'this-has-a')

   txt = 'the quick brown fox jumps over the lazy dog'
   r = slugify(txt, stopwords=['the'])
   self.assertEqual(r, 'quick-brown-fox-jumps-over-lazy-dog')

   txt = 'Foo A FOO B foo C'
   r = slugify(txt, stopwords=['foo'])
   self.assertEqual(r, 'a-b-c')

   txt = 'Foo A FOO B foo C'
   r = slugify(txt, stopwords=['FOO'])
   self.assertEqual(r, 'a-b-c')

   txt = 'the quick brown fox jumps over the lazy dog in a hurry'
   r = slugify(txt, stopwords=['the', 'in', 'a', 'hurry'])
   self.assertEqual(r, 'quick-brown-fox-jumps-over-lazy-dog')


   

   from django.db import models
   from uuslug import uuslug

   
   class CoolSlug(models.Model):
       name = models.CharField(max_length=100)
       slug = models.CharField(max_length=200)

       def __unicode__(self):
           return self.name

       def save(self, *args, **kwargs):
           self.slug = uuslug(self.name, instance=self)
           super(CoolSlug, self).save(*args, **kwargs)

   
   
       self.slug = uuslug(self.name, instance=self, start_no=2)
       

   name = "john"
   c = CoolSlug.objects.create(name=name)
   c.save()
   print(c.slug) # => "john"

   c1 = CoolSlug.objects.create(name=name)
   c1.save()
   print(c1.slug) # => "john-1"

   c2 = CoolSlug.objects.create(name=name)
   c2.save()
   print(c2.slug) # => "john-2"


   
   class SmartTruncatedSlug(models.Model):
       name = models.CharField(max_length=19)
       slug = models.CharField(max_length=10)

       def __unicode__(self):
           return self.name

       def save(self, *args, **kwargs):
           self.slug = uuslug(self.name, instance=self, max_length=10)
           super(SmartTruncatedSlug, self).save(*args, **kwargs)

   
   class AutoTruncatedSlug(models.Model):
       name = models.CharField(max_length=19)
       slug = models.CharField(max_length=19)

       def __unicode__(self):
           return self.name

       def save(self, *args, **kwargs):
           self.slug = uuslug(self.name, instance=self)
           super(SmartTruncatedSlug, self).save(*args, **kwargs)
  ```



  To run the tests against the current environment:

      python manage.py test



  Released under a ([BSD](LICENSE.md)) 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://github.com/un33k/django-uuslug/actions/workflows/main.yml/badge.svg
  [status-link]: https://github.com/un33k/django-uuslug/actions/workflows/main.yml
  [status-image]: https://github.com/un33k/django-uuslug/actions/workflows/main.yml/badge.svg
  [version-image]: https://img.shields.io/pypi/v/django-uuslug.svg
  [version-link]: https://pypi.python.org/pypi/django-uuslug
  [coverage-image]: https://coveralls.io/repos/un33k/django-uuslug/badge.svg
  [coverage-link]: https://coveralls.io/r/un33k/django-uuslug
  [download-image]: https://img.shields.io/pypi/dm/django-uuslug.svg
  [download-link]: https://pypi.python.org/pypi/django-uuslug



  [Neekware Inc.](https://github.com/neekware)


pkgId: ff11cbc393fd39a349fc959e634337f7b8f4338209049a5468506238b05c069d
name: python-django-webpack-loader
arch: src
version: 1.8.1
epoch: 0
release: 1
summary: Transparently use webpack with django
url: https://github.com/django-webpack/django-webpack-loader
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f7872f4f-0e27-4d45-a47a-b50a409e8925
location_href: 00010439-python-django-webpack-loader/python-django-webpack-loader-1.8.1-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://circleci.com/gh/django-webpack/django-webpack-loader/tree/master.svg?style=svg)](https://circleci.com/gh/django-webpack/django-webpack-loader/tree/master)
  [![Coverage Status](https://coveralls.io/repos/github/django-webpack/django-webpack-loader/badge.svg?branch=master)](https://coveralls.io/github/django-webpack/django-webpack-loader?branch=master)
  ![pyversions](https://img.shields.io/pypi/pyversions/django-webpack-loader)
  ![djversions](https://img.shields.io/pypi/djversions/django-webpack-loader)


  Use webpack to generate your static bundles without django's staticfiles or opaque wrappers.


  Django webpack loader consumes the output generated by [webpack-bundle-tracker](https://github.com/owais/webpack-bundle-tracker) and lets you use the generated bundles in django.

  A [changelog](CHANGELOG.md) is also available.




  Test cases cover Django>=2.0 on Python>=3.5. 100% code coverage is the target so we can be sure everything works anytime. It should probably work on older version of django as well but the package does not ship any test cases for them.




  ```bash
  npm install --save-dev webpack-bundle-tracker

  pip install django-webpack-loader
  ```




  Before configuring `django-webpack-loader`, let's first configure what's necessary on `webpack-bundle-tracker` side. Update your Webpack configuration file (it's usually on `webpack.config.js` in the project root). Make sure your file looks like this (adapt to your needs):

  ```javascript
  const path = require('path');
  const webpack = require('webpack');
  const BundleTracker = require('webpack-bundle-tracker');

  module.exports = {
    context: __dirname,
    entry: './assets/js/index',
    output: {
      path: path.resolve('./assets/webpack_bundles/'),
      filename: "[name]-[hash].js"
    },
    plugins: [
      new BundleTracker({filename: './webpack-stats.json'})
    ],
  }
  ```

  The configuration above expects the `index.js` (the app entrypoint file) to live inside the `/assets/js/` directory (this guide going forward will assume that all front-end related files are placed inside the `/assets/` directory, with the different kinds of files arranged within its subdirectories).

  The generated compiled files will be placed inside the `/assets/webpack_bundles/` directory and the file with the information regarding the bundles and assets (`webpack-stats.json`) will be stored in the project root.



  You must generate the front-end bundle using `webpack-bundle-tracker` before using `django-webpack-loader`. You can compile the assets and generate the bundles by running:

  ```bash
  npx webpack --config webpack.config.js --watch
  ```

  This will also generate the stats file. You can also refer to how `django-react-boilerplate` configure the [package.json](https://github.com/vintasoftware/django-react-boilerplate/blob/master/package.json) scripts for different situations.

  > ⚠️ Hot reload is available through a specific config. Check [this section](#hot-reload).

  > ⚠️ This is the recommended usage for the development environment. For **usage in production**, please refer to [this section](#usage-in-production)


  First of all, add `webpack_loader` to `INSTALLED_APPS`.
  ```python
  INSTALLED_APPS = (
    ...
    'webpack_loader',
    ...
  )
  ```

  Below is the recommended setup for the Django settings file when using `django-webpack-loader`.

  ```python
  WEBPACK_LOADER = {
    'DEFAULT': {
      'CACHE': not DEBUG,
      'STATS_FILE': os.path.join(BASE_DIR, 'webpack-stats.json'),
      'POLL_INTERVAL': 0.1,
      'IGNORE': [r'.+\.hot-update.js', r'.+\.map'],
    }
  }
  ```

  For that setup, we're using the `DEBUG` variable provided by Django. Since in a production environment (`DEBUG = False`) the assets files won't constantly change, we can safely cache the results (`CACHE=True`) and optimize our flow, as `django-webpack-loader` will read the stats file only once and store the assets files paths in memory. From that point onwards, it will use these stored paths as the source of truth. If `CACHE=False`, we'll always read the stats file to get the assets paths.
  > ⚠️ If `CACHE=True`, any changes made in the assets files will only be read when the web workers are restarted.

  During development, when the stats file changes a lot, we want to always poll for its updated version (in our case, we'll fetch it every 0.1s, as defined on `POLL_INTERVAL`).
  > ⚠️ In production (`DEBUG=False`), we'll only fetch the stats file once, so `POLL_INTERVAL` is ignored.

  While `CACHE` isn't directly related to `POLL_INTERVAL`, it's interesting to keep `CACHE` binded to the `DEBUG` logic value (in this case, the negation of the logic value) in order to only cache the assets in production, as we'd not continuously poll the stats file in that environment.

  The `STATS_FILE` parameter represents the output file produced by `webpack-bundle-tracker`. Since in the Webpack configuration file we've named it `webpack-stats.json` and stored it on the project root, we must replicate that setting on the back-end side.

  `IGNORE` is a list of regular expressions. If a file generated by Webpack matches one of the expressions, the file will not be included in the template.



  - `TIMEOUT` is the number of seconds webpack_loader should wait for webpack to finish compiling before raising an exception. `0`, `None` or leaving the value out of settings disables timeouts

  - `INTEGRITY` is flag enabling [Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) on rendered `<script>` and `<link>` tags.  Integrity hash is get from stats file and configuration on side of `BundleTracker`, where configuration option `integrity: true` is required.

  - `LOADER_CLASS` is the fully qualified name of a python class as a string that holds the custom webpack loader. This is where behavior can be customized as to how the stats file is loaded. Examples include loading the stats file from a database, cache, external url, etc. For convenience, `webpack_loader.loader.WebpackLoader` can be extended. The `load_assets` method is likely where custom behavior will be added. This should return the stats file as an object.

  - `SKIP_COMMON_CHUNKS` is a flag which prevents already generated chunks from being included again in the same page. This should only happen if you use more than one entrypoint per Django template (multiple `render_bundle` calls). By enabling this, you can get the same default behavior of the [HtmlWebpackPlugin](https://webpack.js.org/plugins/html-webpack-plugin/). The same caveats apply as when using `skip_common_chunks` on `render_bundle`, see that section below for more details.

  Here's a simple example of loading from an external url:

    ```py
    import requests
    from webpack_loader.loader import WebpackLoader

    class ExternalWebpackLoader(WebpackLoader):
      def load_assets(self):
        url = self.config['STATS_URL']
        return requests.get(url).json()
    ```


  In order to render the front-end code into the Django templates, we use the `render_bundle` template tag.

  Its behavior is to accept a string with the name of an entrypoint from the stats file (in our case, we're using `main`, which is [the default](https://webpack.js.org/concepts/entry-points/#single-entry-shorthand-syntax)) and it'll proceed to include all files under that entrypoint. You can read more about the entrypoints concept [here](https://webpack.js.org/concepts/entry-points/).

  > ⚠️ You can also check an example on how to use multiple `entry` values [here](https://github.com/django-webpack/django-webpack-loader/tree/master/examples/code-splitting).

  Below is the basic usage for `render_bundle` within a template:

  ```HTML+Django
  {% load render_bundle from webpack_loader %}

  {% render_bundle 'main' %}
  ```

  That will render the proper `<script>` and `<link>` tags needed in your template.


  For `django-webpack-loader` to work, you must run the webpack pipeline. Please refer to [this section](#compiling-the-front-end-assets).

  In summary, you should do the following:

  ```bash

  npx webpack --config webpack.config.js --watch


  python manage.py runserver
  ```

  > ⚠️ You can also check [this example](https://github.com/django-webpack/django-webpack-loader/tree/master/examples/simple) on how to run a project with `django-webpack-loader` and `webpack-bundle-track`.


  We recommend that you keep your local bundles and the stats file outside the version control, having a production pipeline that will compile and collect the assets during the deployment phase.

  You must add `STATICFILES_DIRS` to your settings file, pointing to the directory where the static files are located. This will let `collectstatic` know where it should look at:
  ```python
  STATICFILES_DIRS = (
    os.path.join(BASE_DIR, 'assets'),
  )
  ```

  Below are the commands that should be run to compile and collect the static files (please note this may change from platform to platform):
  ```
  npm run build
  python manage.py collectstatic --noinput
  ```

  First we build the assets and, since we have `webpack-bundle-tracker` in our front-end building pipeline, the stats file will be populated. Then, we manually run collecstatic to collect the compiled assets.

  > ⚠️ Heroku is one platform that automatically runs collectstatic for you, so you need to set `DISABLE_COLLECTSTATIC=1` environment var. Instead, you must manually run collectstatic after running webpack. In Heroku, this is achieved with a `post_compile` hook. You can see an example on how to implement this flow on [django-react-boilerplate](https://github.com/vintasoftware/django-react-boilerplate/tree/master/bin).

  However, production usage for this package is **fairly flexible**. Other approaches may include keeping the production bundles in the version control and take that responsibility from the automatic pipeline. However, you must remember to always build the frontend and generate the bundle before pushing to remote.


  To run tests where `render_bundle` shows up, since we don't have `webpack-bundle-tracker` at that point to generate the stats file, the calls to render the bundle will fail. The solution is to use the `FakeWebpackLoader` in your test settings:

  ```python
  WEBPACK_LOADER['DEFAULT']['LOADER_CLASS'] = 'webpack_loader.loader.FakeWebpackLoader'
  ```




  `render_bundle` also takes a second argument which can be a file extension to match. This is useful when you want to render different types for files in separately. For example, to render CSS in head and JS at bottom we can do something like this,

  ```HTML+Django
  {% load render_bundle from webpack_loader %}

  <html>
    <head>
      {% render_bundle 'main' 'css' %}
    </head>
    <body>
      ....
      {% render_bundle 'main' 'js' %}
    </body>
  </head>
  ```


  The `is_preload=True` option in the `render_bundle` template tag can be used to add `rel="preload"` link tags.

  ```HTML+Django
  {% load render_bundle from webpack_loader %}

  <html>
    <head>
      {% render_bundle 'main' 'css' is_preload=True %}
      {% render_bundle 'main' 'js' is_preload=True %}

      {% render_bundle 'main' 'css' %}
    </head>

    <body>
      {% render_bundle 'main' 'js' %}
    </body>
  </html>
  ```


  `webpack_static` template tag provides facilities to load static assets managed by webpack in Django templates. It is like Django's built in `static` tag but for webpack assets instead.

  In the below example, `logo.png` can be any static asset shipped with any npm package.

  ```HTML+Django
  {% load webpack_static from webpack_loader %}

  <!-- render full public path of logo.png -->
  <img src="{% webpack_static 'logo.png' %}"/>
  ```
  The public path is based on `webpack.config.js` [output.publicPath](https://webpack.js.org/configuration/output/#output-publicpath).

  Please note that this approach will use the original asset file, and not a post-processed one from the Webpack pipeline, in case that file had gone through such flow (i.e.: You've imported an image on the React side and used it there, the file used within the React components will probably have a hash string on its name, etc. This processed file will be different than the one you'll grab with `webpack_static`).


  You can use the parameter `skip_common_chunks=True` or `skip_common_chunks=False` to override the global `SKIP_COMMON_CHUNKS` setting for a specific bundle.

  In order for this option to work, `django-webpack-loader` requires the `request` object to be in the context, to be able to keep track of the generated chunks.

  The `request` object is passed by default via the `django.template.context_processors.request` middleware with using the Django built-in templating system, and also with using Jinja2.

  If you don't have `request` in the context for some reason (e.g. using `Template.render` or `render_to_string` directly without passing the request), you'll get warnings on the console and the common chunks will remain duplicated.


  The `suffix` option can be used to append a string at the end of the file URL. For instance, it can be used if your webpack configuration emits compressed `.gz` files.
  qwe
  ```HTML+Django
  {% load render_bundle from webpack_loader %}
  <html>
    <head>
      <meta charset="UTF-8">
      <title>Example</title>
      {% render_bundle 'main' 'css' %}
    </head>
    <body>
      {% render_bundle 'main' 'js' suffix='.gz' %}
    </body>
  </html>
  ```


  Version 1.0 and up of `django-webpack-loader` also supports multiple Webpack configurations. The following configuration defines 2 Webpack stats files in settings and uses the `config` argument in the template tags to influence which stats file to load the bundles from.

  ```python
  WEBPACK_LOADER = {
      'DEFAULT': {
          'BUNDLE_DIR_NAME': 'bundles/',
          'STATS_FILE': os.path.join(BASE_DIR, 'webpack-stats.json'),
      },
      'DASHBOARD': {
          'BUNDLE_DIR_NAME': 'dashboard_bundles/',
          'STATS_FILE': os.path.join(BASE_DIR, 'webpack-stats-dashboard.json'),
      }
  }
  ```

  ```HTML+Django
  {% load render_bundle from webpack_loader %}

  <html>
    <body>
      ....
      {% render_bundle 'main' 'js' 'DEFAULT' %}
      {% render_bundle 'main' 'js' 'DASHBOARD' %}

      <!-- or render all files from a bundle -->
      {% render_bundle 'main' config='DASHBOARD' %}

      <!-- the following tags do the same thing -->
      {% render_bundle 'main' 'css' 'DASHBOARD' %}
      {% render_bundle 'main' extension='css' config='DASHBOARD' %}
      {% render_bundle 'main' config='DASHBOARD' extension='css' %}

      <!-- add some extra attributes to the tag -->
      {% render_bundle 'main' 'js' 'DEFAULT' attrs='async charset="UTF-8"'%}
    </body>
  </head>
  ```



  If you need the URL to an asset without the HTML tags, the `get_files` template tag can be used. A common use case is specifying the URL to a custom css file for a Javascript plugin.

  `get_files` works exactly like `render_bundle` except it returns a list of matching files and lets you assign the list to a custom template variable.

  Each object in the returned list has 2 properties:
  1. `name`, which is the name of a chunk from the stats file;
  2. `url`, which can be:
    1. The `publicPath` if the asset has one;
    2. The `path` to the asset in the static files storage, if the asset doesn't have a `publicPath`.

  For example:

  ```HTML+Django
  {% load get_files from webpack_loader %}

  {% get_files 'editor' 'css' as editor_css_files %}
  CKEDITOR.config.contentsCss = '{{ editor_css_files.0.url }}';

  <!-- or list down name and url for every file -->
  <ul>
  {% for css_file in editor_css_files %}
      <li>{{ css_file.name }} : {{ css_file.url }}</li>
  {% endfor %}
  </ul>
  ```


  In case you wish to use [code-splitting](https://webpack.js.org/guides/code-splitting/), follow the recipe below on the Javascript side.

  Create your entrypoint file and add elements to the DOM, while leveraging the lazy imports.
  ```js
  // src/principal.js
  function getComponent() {
    return import(/* webpackChunkName: "lodash" */ 'lodash').then(({ default: _ }) => {
      const element = document.createElement('div');

      element.innerHTML = _.join(['Hello', 'webpack'], ' ');

      return element;
    }).catch(error => 'An error occurred while loading the component');
  }

  getComponent().then((component) => {
    document.body.appendChild(component);
  })
  ```

  On your configuration file, do the following:
  ```js
  // webpack.config.js
  module.exports = {
    context: __dirname,
    entry: {
      principal: './src/principal',
    },
    output: {
      path: path.resolve('./dist/'),
      // publicPath should match your STATIC_URL config.
      // This is required otherwise webpack will try to fetch
      // our chunk generated by the dynamic import from "/" instead of "/dist/".
      publicPath: '/dist/',
      chunkFilename: '[name].bundle.js',
      filename: "[name]-[hash].js"
    },
    plugins: [
      new BundleTracker({ filename: './webpack-stats.json' })
    ]
  }
  ```

  If you're using Webpack 5 instead of 4, do the following:
  - Change `filename: "[name]-[hash].js"` to `filename: "[name]-[fullhash].js"`;
  - Remove `/* webpackChunkName: "lodash" */`, which is not needed anymore.

  On your template, render the bundle as usual:

  ```HTML+Django
  <!-- index.html -->
  {% load render_bundle from webpack_loader %}

  <!DOCTYPE html>
  <html>
    <head>
      <meta charset="utf-8">
      <title>My test page</title>
    </head>
    <body>
      <p>This is my page</p>

      {% render_bundle 'principal' 'js' %}
    </body>
  </html>
  ```


  In case you wish to enable hot reload for your project using `django-webpack-loader` and `webpack-bundle-tracker`, please check out [this example](https://github.com/django-webpack/django-webpack-loader/tree/master/examples/hot-reload), in particular how [server.js](https://github.com/django-webpack/django-webpack-loader/blob/master/examples/hot-reload/server.js) and [webpack.config.js](https://github.com/django-webpack/django-webpack-loader/blob/master/examples/hot-reload/webpack.config.js) are configured.



  If you need to output your assets in a jinja template, we provide a Jinja2 extension that's compatible with [django-jinja](https://github.com/niwinz/django-jinja).

  To install the extension, add it to the `TEMPLATES` configuration in the `["OPTIONS"]["extension"]` list.

  ```python
  from django_jinja.builtins import DEFAULT_EXTENSIONS
  TEMPLATES = [
    {
      "BACKEND": "django_jinja.backend.Jinja2",
      "OPTIONS": {
        "extensions": DEFAULT_EXTENSIONS + [
          "webpack_loader.contrib.jinja2ext.WebpackExtension",
        ],
      }
    }
  ]
  ```

  Then in your base jinja template, do:

  ```HTML
  {{ render_bundle('main') }}
  ```



  In order to use `django-webpack-loader>=1.0.0`, you must ensure that `webpack-bundle-tracker@1.0.0` is being used on the JavaScript side. It's recommended that you always keep at least minor version parity across both packages, for full compatibility.

  This is necessary because the formatting of `webpack-stats.json` that `webpack-bundle-tracker` outputs has changed starting at version `1.0.0-alpha.1`. Starting at `django-webpack-loader==1.0.0`, this is the only formatting accepted here, meaning that other versions of that package don't output compatible files anymore, thereby breaking compatibility with older `webpack-bundle-tracker` releases.



  [![alt text](https://avatars2.githubusercontent.com/u/5529080?s=80&v=4 "Vinta Logo")](https://www.vinta.com.br/)

  This project is maintained by [Vinta Software](https://www.vinta.com.br/) and is used in products of Vinta's clients. We are always looking for exciting work, so if you need any commercial support, feel free to get in touch: contact@vinta.com.br


pkgId: 0e51ef0e824402a61460d0730ea694f0d3fc4a2c97c7e5f0e1fc5fcb8b2ce83e
name: python-djangoql
arch: src
version: 0.17.1
epoch: 0
release: 1
summary: DjangoQL: Advanced search language for Django
url: https://github.com/ivelum/djangoql/
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-95989531-6078-4a55-8d18-05c6a7ea7986
location_href: 00003504-python-djangoql/python-djangoql-0.17.1-1.src.rpm
checksum_type: sha256
description:
  Advanced search language for Django, with auto-completion. Supports logical
  operators, parenthesis, table joins, and works with any Django model. Tested on
  Python 2.7, 3.5 - 3.10, Django 1.8 - 4.0. The auto-completion feature has been
  tested in Chrome, Firefox, Safari, IE9+.
  See a video: `DjangoQL demo <https://youtu.be/oKVff4dHZB8>`_
  DjangoQL is used by:
  |logo1| |logo2| |logo3| |logo4|
  Is your project using DjangoQL? Please submit a PR and let us know!


pkgId: 77866fecb71a209414e0184f37b7557511d3010cdea2f79d0757f8e6c7a3cab6
name: python-djangorestframework
arch: src
version: 3.14.0
epoch: 0
release: 1
summary: Web APIs for Django, made easy.
url: https://www.django-rest-framework.org/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-97e31834-c1b5-4f64-a7ac-d43100cbc080
location_href: 00009219-python-djangorestframework/python-djangorestframework-3.14.0-1.src.rpm
checksum_type: sha256
description:
  REST framework is a *collaboratively funded project*. If you use
  REST framework commercially we strongly encourage you to invest in its
  continued development by [signing up for a paid plan][funding].
  The initial aim is to provide a single full-time position on REST framework.
  *Every single sign-up makes a significant impact towards making that possible.*
  [![][sentry-img]][sentry-url]
  [![][stream-img]][stream-url]
  [![][spacinov-img]][spacinov-url]
  [![][retool-img]][retool-url]
  [![][bitio-img]][bitio-url]
  [![][posthog-img]][posthog-url]
  [![][cryptapi-img]][cryptapi-url]
  [![][fezto-img]][fezto-url]


pkgId: 6d97aacd044619c81c2b6c734513896c907e926f9f673332ed1c7ba260ebde4b
name: python-djangorestframework-api-key
arch: src
version: 2.3.0
epoch: 0
release: 1
summary: API key permissions for the Django REST Framework
url: http://github.com/florimondmanca/djangorestframework-api-key
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6fbf7056-f576-4dad-831b-4992424586fa
location_href: 00011655-python-djangorestframework-api-key/python-djangorestframework-api-key-2.3.0-1.src.rpm
checksum_type: sha256
description:
  API key permissions for the [Django REST Framework](https://www.django-rest-framework.org).

  <div>
    <a href="https://dev.azure.com/florimondmanca/public/_build/latest?definitionId=7&branchName=master">
        <img src="https://dev.azure.com/florimondmanca/public/_apis/build/status/florimondmanca.djangorestframework-api-key?branchName=master" alt="build status"/>
    </a>
    <a href="https://codecov.io/gh/florimondmanca/djangorestframework-api-key">
        <img src="https://codecov.io/gh/florimondmanca/djangorestframework-api-key/branch/master/graph/badge.svg" alt="coverage">
    </a>
    <a href="https://pypi.org/project/djangorestframework-api-key">
        <img src="https://badge.fury.io/py/djangorestframework-api-key.svg" alt="package version"/>
    </a>
  </div>
  <div>
    <img src="https://img.shields.io/pypi/pyversions/djangorestframework-api-key.svg" alt="python versions"/>
    <img src="https://img.shields.io/pypi/djversions/djangorestframework-api-key.svg?colorB=44b78b" alt="django versions"/>
    <img src="https://img.shields.io/badge/drf-3.8+-7f2d2d.svg" alt="drf versions"/>
  </div>



  **Django REST Framework API Key is a library for allowing server-side clients to safely use your API.** These clients are typically third-party backends and services (i.e. _machines_) which do not have a user account but still need to interact with your API in a secure way.



  - ✌️ **Simple to use**: create, view and revoke API keys via the admin site, or use built-in helpers to create API keys programmatically.
  - 🔒 **As secure as possible**: API keys are treated with the same level of care as user passwords. They are hashed using the default password hasher before being stored in the database, and only visible at creation.
  - 🎨 **Customizable**: satisfy specific business requirements by building your own customized API key models, permission classes and admin panels.



  There are important security aspects you need to consider before switching to an API key access control scheme. We've listed some of these in [Security caveats](docs/security.md#caveats), including serving your API over HTTPS.

  Besides, see [Why and when to use API keys](https://cloud.google.com/endpoints/docs/openapi/when-why-api-key#top_of_page) for hints on whether API keys can fit your use case.

  API keys are ideal in the following situations:

  - Blocking anonymous traffic.
  - Implementing API key-based [throttling](https://www.django-rest-framework.org/api-guide/throttling/). (Note that Django REST Framework already has may built-in utilities for this use case.)
  - Identifying usage patterns by logging request information along with the API key.

  They can also present enough security for authorizing internal services, such as your API server and an internal frontend application.

  > Please note that this package is NOT meant for authentication. You should NOT use this package to identify individual users, either directly or indirectly.
  >
  > If you need server-to-server authentication, you may want to consider OAuth instead. Libraries such as [django-oauth-toolkit](https://django-oauth-toolkit.readthedocs.io/en/latest/index.html) can help.



  Install with `pip`:

  ```bash
  pip install "djangorestframework-api-key==2.*"
  ```

  _**Note**: It is highly recommended to **pin your dependency** to the latest major version (as depicted above), as breaking changes may and will happen between major releases._

  Add the app to your `INSTALLED_APPS`:

  ```python


  INSTALLED_APPS = [
    
    "rest_framework",
    "rest_framework_api_key",
  ]
  ```

  Run the included migrations:

  ```bash
  python manage.py migrate
  ```

  To learn how to configure permissions and manage API keys, head to the [Documentation](https://florimondmanca.github.io/djangorestframework-api-key).



  See [CHANGELOG.md](https://github.com/florimondmanca/djangorestframework-api-key/tree/master/CHANGELOG.md).



  See [CONTRIBUTING.md](https://github.com/florimondmanca/djangorestframework-api-key/tree/master/CONTRIBUTING.md).



  MIT




  All notable changes to this project will be documented in this file.

  The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).





  - Drop support for Python 3.6, which has reached EOL. (Pull #210)



  - Fix migration 0004 when run against a non default database. (Pull #215)





  - Added support for Django config detection for different versions (PR #187)



  - Add official support for Django 3.2 and Python 3.9 and 3.10 (PR #189)
  - Bumped `hashed_key` field's `max_length` from 100 to 150 to address length issue with `argon2-cffi` (PR #193)





  - Add support for custom API `keyword`. (Pull #175)



  **NOTE**: this release drops compatibility with certain Python and Django versions, but contains no other breaking changes. See [Upgrade to 2.0](https://florimondmanca.github.io/djangorestframework-api-key/upgrade/2.0/) for detailed migration steps.



  - Dropped support for Django 2.0 and Django 2.1. (Pull #126)
  - Dropped support for Python 3.5. (Pull #84)



  - Add support for Django 3.0. (Pull #82)
  - Add support for Python 3.8. (Pull #81)
  - Add `BaseAPIKeyManager.get_from_key()` to allow retrieving API keys from views. (Pull #93)
  - Add type annotations, and partial support for `django-stubs` and `djangorestframework-stubs`. (Pull #88, Pull #122)





  - Now ships with type annotations ([PEP 561](https://www.python.org/dev/peps/pep-0561/)). (Pull #73)



  **NOTE**: this release contains migrations. See [Upgrade to v1.4](https://florimondmanca.github.io/djangorestframework-api-key/upgrade/1.4/) for detailed instructions.



  - The `prefix` and `hashed_key` are now stored in dedicated fields on the `APIKey` model. (Pull #62)



  **NOTE**: this release contains migrations. In your Django project, run them using:

  ```python
  python manage.py migrate rest_framework_api_key
  ```



  - Add abstract API key model (`AbstractAPIKey`) and base manager (`BaseAPIKeyManager`). (Pull #36)
  - Add base permissions (`BaseHasAPIKey`). (Pull #46)



  - The `id` field of `APIKey` is now non-`editable`.
  - `APIKeyModelAdmin` does not define `fieldsets` anymore. This allows subclasses to benefit from Django's automatic fieldsets. (Pull #52)



  - Explicitly use `utf-8` encoding in `setup.py`, which could previously lead to issues when installing on certain systems. (Pull #58)





  - Fixed a critical bug in `APIKeyModelAdmin` that prevented `rest_framework_api_key` from passing Django system checks. (Pull #39)



  **NOTE**: this release contains migrations. In your Django project, run them using:

  ```python
  python manage.py migrate rest_framework_api_key
  ```



  - API keys can now have an optional `expiry_date`. (Pull #33) `HasAPIKey` denies access if the API key has expired, i.e. if `expiry_date`, if set, is in the past.
  - It is now possible to search by `prefix` in the API key admin panel.
  - The `prefix` is now displayed in the edit view of the API key admin panel.





  - Improve documentation on which password hasher is used.
  - Add tests against the Argon2, BcryptSHA256 and PBKDF2SHA1 hashers. (Pull #32)



  - Fix support for password hashers that generate hashes that contain dots. (Pull #31)



  **This release is incompatible with 0.x**. See [Upgrade to 1.0](https://florimondmanca.github.io/djangorestframework-api-key/upgrade/1.4/) for migration steps.



  - Remove `HasAPIKeyOrIsAuthenticated` permission class. You should use bitwise composition now, e.g. `HasAPIKey | IsAuthenticated`.
  - Drop the `DRF_API_KEY_*` settings. (Pull #19)



  - Switch to a new API key generation and validation scheme. Clients must now authorize using a single API key header (Pull #19). The header is `Authorization` by default. It can be customized using the `API_KEY_CUSTOM_HEADER` setting (Pull #26). Use the `name` field to identify clients.



  - Add support for Django 2.2. (Pull #27)
  - Add programmatic API key creation using `APIKey.objects.create_key()`. (Pull #19)



  - Improved API key storage using Django's password hashing helpers. (Uses the default Django password hasher.) (Pull #19)





  - Drop support for Python 3.4. Only 3.5, 3.6 and 3.7 are supported now.
  - Drop support for Django < 2.0. Only 2.0 and 2.1 are supported now.



  - `HasAPIKey` now implements `.has_object_permissions()`, which allows to compose it with other permission classes and perform object-level permission checks. (Pull #25)



  _Initial changelog entry._



  - `APIKey` model.
  - `HasAPIKey` and `HasAPIKeyOrIsAuthenticated` permission classes.
  - Generate, view and revoke API keys from the Django admin.
  - Authenticate requests using the `Api-Token` and `Api-Secret-Key` headers. Customizable via the `DRF_API_KEY_TOKEN_HEADER` and `DRF_API_KEY_SECRET_KEY_HEADER` settings.


pkgId: f94d24e95ac8c933c87b7faf9f9920e9c2075ece79d1988b4d84561689ff9a5c
name: python-djangorestframework-api-key-help
arch: noarch
version: 2.3.0
epoch: 0
release: 1
summary: Development documents and examples for djangorestframework-api-key
url: http://github.com/florimondmanca/djangorestframework-api-key
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6fbf7056-f576-4dad-831b-4992424586fa
rpm_sourcerpm: python-djangorestframework-api-key-2.3.0-1.src.rpm
checksum_type: sha256
description:
  API key permissions for the [Django REST Framework](https://www.django-rest-framework.org).

  <div>
    <a href="https://dev.azure.com/florimondmanca/public/_build/latest?definitionId=7&branchName=master">
        <img src="https://dev.azure.com/florimondmanca/public/_apis/build/status/florimondmanca.djangorestframework-api-key?branchName=master" alt="build status"/>
    </a>
    <a href="https://codecov.io/gh/florimondmanca/djangorestframework-api-key">
        <img src="https://codecov.io/gh/florimondmanca/djangorestframework-api-key/branch/master/graph/badge.svg" alt="coverage">
    </a>
    <a href="https://pypi.org/project/djangorestframework-api-key">
        <img src="https://badge.fury.io/py/djangorestframework-api-key.svg" alt="package version"/>
    </a>
  </div>
  <div>
    <img src="https://img.shields.io/pypi/pyversions/djangorestframework-api-key.svg" alt="python versions"/>
    <img src="https://img.shields.io/pypi/djversions/djangorestframework-api-key.svg?colorB=44b78b" alt="django versions"/>
    <img src="https://img.shields.io/badge/drf-3.8+-7f2d2d.svg" alt="drf versions"/>
  </div>



  **Django REST Framework API Key is a library for allowing server-side clients to safely use your API.** These clients are typically third-party backends and services (i.e. _machines_) which do not have a user account but still need to interact with your API in a secure way.



  - ✌️ **Simple to use**: create, view and revoke API keys via the admin site, or use built-in helpers to create API keys programmatically.
  - 🔒 **As secure as possible**: API keys are treated with the same level of care as user passwords. They are hashed using the default password hasher before being stored in the database, and only visible at creation.
  - 🎨 **Customizable**: satisfy specific business requirements by building your own customized API key models, permission classes and admin panels.



  There are important security aspects you need to consider before switching to an API key access control scheme. We've listed some of these in [Security caveats](docs/security.md#caveats), including serving your API over HTTPS.

  Besides, see [Why and when to use API keys](https://cloud.google.com/endpoints/docs/openapi/when-why-api-key#top_of_page) for hints on whether API keys can fit your use case.

  API keys are ideal in the following situations:

  - Blocking anonymous traffic.
  - Implementing API key-based [throttling](https://www.django-rest-framework.org/api-guide/throttling/). (Note that Django REST Framework already has may built-in utilities for this use case.)
  - Identifying usage patterns by logging request information along with the API key.

  They can also present enough security for authorizing internal services, such as your API server and an internal frontend application.

  > Please note that this package is NOT meant for authentication. You should NOT use this package to identify individual users, either directly or indirectly.
  >
  > If you need server-to-server authentication, you may want to consider OAuth instead. Libraries such as [django-oauth-toolkit](https://django-oauth-toolkit.readthedocs.io/en/latest/index.html) can help.



  Install with `pip`:

  ```bash
  pip install "djangorestframework-api-key==2.*"
  ```

  _**Note**: It is highly recommended to **pin your dependency** to the latest major version (as depicted above), as breaking changes may and will happen between major releases._

  Add the app to your `INSTALLED_APPS`:

  ```python


  INSTALLED_APPS = [
    
    "rest_framework",
    "rest_framework_api_key",
  ]
  ```

  Run the included migrations:

  ```bash
  python manage.py migrate
  ```

  To learn how to configure permissions and manage API keys, head to the [Documentation](https://florimondmanca.github.io/djangorestframework-api-key).



  See [CHANGELOG.md](https://github.com/florimondmanca/djangorestframework-api-key/tree/master/CHANGELOG.md).



  See [CONTRIBUTING.md](https://github.com/florimondmanca/djangorestframework-api-key/tree/master/CONTRIBUTING.md).



  MIT




  All notable changes to this project will be documented in this file.

  The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).





  - Drop support for Python 3.6, which has reached EOL. (Pull #210)



  - Fix migration 0004 when run against a non default database. (Pull #215)





  - Added support for Django config detection for different versions (PR #187)



  - Add official support for Django 3.2 and Python 3.9 and 3.10 (PR #189)
  - Bumped `hashed_key` field's `max_length` from 100 to 150 to address length issue with `argon2-cffi` (PR #193)





  - Add support for custom API `keyword`. (Pull #175)



  **NOTE**: this release drops compatibility with certain Python and Django versions, but contains no other breaking changes. See [Upgrade to 2.0](https://florimondmanca.github.io/djangorestframework-api-key/upgrade/2.0/) for detailed migration steps.



  - Dropped support for Django 2.0 and Django 2.1. (Pull #126)
  - Dropped support for Python 3.5. (Pull #84)



  - Add support for Django 3.0. (Pull #82)
  - Add support for Python 3.8. (Pull #81)
  - Add `BaseAPIKeyManager.get_from_key()` to allow retrieving API keys from views. (Pull #93)
  - Add type annotations, and partial support for `django-stubs` and `djangorestframework-stubs`. (Pull #88, Pull #122)





  - Now ships with type annotations ([PEP 561](https://www.python.org/dev/peps/pep-0561/)). (Pull #73)



  **NOTE**: this release contains migrations. See [Upgrade to v1.4](https://florimondmanca.github.io/djangorestframework-api-key/upgrade/1.4/) for detailed instructions.



  - The `prefix` and `hashed_key` are now stored in dedicated fields on the `APIKey` model. (Pull #62)



  **NOTE**: this release contains migrations. In your Django project, run them using:

  ```python
  python manage.py migrate rest_framework_api_key
  ```



  - Add abstract API key model (`AbstractAPIKey`) and base manager (`BaseAPIKeyManager`). (Pull #36)
  - Add base permissions (`BaseHasAPIKey`). (Pull #46)



  - The `id` field of `APIKey` is now non-`editable`.
  - `APIKeyModelAdmin` does not define `fieldsets` anymore. This allows subclasses to benefit from Django's automatic fieldsets. (Pull #52)



  - Explicitly use `utf-8` encoding in `setup.py`, which could previously lead to issues when installing on certain systems. (Pull #58)





  - Fixed a critical bug in `APIKeyModelAdmin` that prevented `rest_framework_api_key` from passing Django system checks. (Pull #39)



  **NOTE**: this release contains migrations. In your Django project, run them using:

  ```python
  python manage.py migrate rest_framework_api_key
  ```



  - API keys can now have an optional `expiry_date`. (Pull #33) `HasAPIKey` denies access if the API key has expired, i.e. if `expiry_date`, if set, is in the past.
  - It is now possible to search by `prefix` in the API key admin panel.
  - The `prefix` is now displayed in the edit view of the API key admin panel.





  - Improve documentation on which password hasher is used.
  - Add tests against the Argon2, BcryptSHA256 and PBKDF2SHA1 hashers. (Pull #32)



  - Fix support for password hashers that generate hashes that contain dots. (Pull #31)



  **This release is incompatible with 0.x**. See [Upgrade to 1.0](https://florimondmanca.github.io/djangorestframework-api-key/upgrade/1.4/) for migration steps.



  - Remove `HasAPIKeyOrIsAuthenticated` permission class. You should use bitwise composition now, e.g. `HasAPIKey | IsAuthenticated`.
  - Drop the `DRF_API_KEY_*` settings. (Pull #19)



  - Switch to a new API key generation and validation scheme. Clients must now authorize using a single API key header (Pull #19). The header is `Authorization` by default. It can be customized using the `API_KEY_CUSTOM_HEADER` setting (Pull #26). Use the `name` field to identify clients.



  - Add support for Django 2.2. (Pull #27)
  - Add programmatic API key creation using `APIKey.objects.create_key()`. (Pull #19)



  - Improved API key storage using Django's password hashing helpers. (Uses the default Django password hasher.) (Pull #19)





  - Drop support for Python 3.4. Only 3.5, 3.6 and 3.7 are supported now.
  - Drop support for Django < 2.0. Only 2.0 and 2.1 are supported now.



  - `HasAPIKey` now implements `.has_object_permissions()`, which allows to compose it with other permission classes and perform object-level permission checks. (Pull #25)



  _Initial changelog entry._



  - `APIKey` model.
  - `HasAPIKey` and `HasAPIKeyOrIsAuthenticated` permission classes.
  - Generate, view and revoke API keys from the Django admin.
  - Authenticate requests using the `Api-Token` and `Api-Secret-Key` headers. Customizable via the `DRF_API_KEY_TOKEN_HEADER` and `DRF_API_KEY_SECRET_KEY_HEADER` settings.

location_href:
  00011655-python-djangorestframework-api-key/python-djangorestframework-api-key-help-2.3.0-1.noarch.rpm


pkgId: fcad5da5e1a4c3459a414a938d390c651ed5169ce23246bafc00099351bb220f
name: python-djangorestframework-camel-case
arch: src
version: 1.4.2
epoch: 0
release: 1
summary: Camel case JSON support for Django REST framework.
url: https://github.com/vbabiy/djangorestframework-camel-case
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bec1fecb-9ce2-4777-be98-d7cafb7926b3
checksum_type: sha256
location_href:
  00011030-python-djangorestframework-camel-case/python-djangorestframework-camel-case-1.4.2-1.src.rpm


pkgId: d8a4283def24f7af65cb0a8bdb93cd521548fff84fd114dd7b92c88a318962d3
name: python-djangorestframework-camel-case-help
arch: noarch
version: 1.4.2
epoch: 0
release: 1
summary: Development documents and examples for djangorestframework-camel-case
url: https://github.com/vbabiy/djangorestframework-camel-case
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bec1fecb-9ce2-4777-be98-d7cafb7926b3
rpm_sourcerpm: python-djangorestframework-camel-case-1.4.2-1.src.rpm
checksum_type: sha256
location_href:
  00011030-python-djangorestframework-camel-case/python-djangorestframework-camel-case-help-1.4.2-1.noarch.rpm


pkgId: e74b480dec56923e9885f50f073e7a96d10d622b45812f4b61287d17d6308fb7
name: python-djangorestframework-gis
arch: src
version: 1.0
epoch: 0
release: 1
summary: Geographic add-ons for Django Rest Framework
url: https://github.com/openwisp/django-rest-framework-gis
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-10387c9c-743d-46c8-b2fd-25038f8ee278
location_href: 00012166-python-djangorestframework-gis/python-djangorestframework-gis-1.0-1.src.rpm
checksum_type: sha256
description:
  |Build Status| |Coverage Status| |Requirements Status| |PyPI version| |PyPI downloads| |Black|
  Geographic add-ons for Django Rest Framework - `Mailing
  List <http://bit.ly/1M4sLTp>`__.


pkgId: e71bdea76002fb218299778a768fc187b1547bbb237e218e4a7f38138fcd484c
name: python-djangorestframework-jsonapi-help
arch: noarch
version: 6.0.0
epoch: 0
release: 1
summary: Development documents and examples for djangorestframework-jsonapi
url: https://github.com/django-json-api/django-rest-framework-json-api
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a6ee2986-3a6e-4fa2-969d-7a3f6110ecd8
rpm_sourcerpm: python-djangorestframework-jsonapi-6.0.0-1.src.rpm
checksum_type: sha256
location_href:
  00013865-python-djangorestframework-jsonapi/python-djangorestframework-jsonapi-help-6.0.0-1.noarch.rpm


pkgId: 752929c6c6454ffda285bb648c2e5136d93acf29ffa126b322fc17beaaa56662
name: python-djangorestframework-jwt
arch: src
version: 1.11.0
epoch: 0
release: 1
summary: JSON Web Token based authentication for Django REST framework
url: https://github.com/GetBlimp/django-rest-framework-jwt
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6c94884a-941f-43d6-a694-7c9b3edae7e5
location_href: 00010320-python-djangorestframework-jwt/python-djangorestframework-jwt-1.11.0-1.src.rpm
checksum_type: sha256
description:
  |build-status-image| |pypi-version|
  **JSON Web Token Authentication support for Django REST Framework**
  Full documentation for the project is available at `docs`_.


pkgId: c0c9ad176079cbc774172998b5e3920e151ee0a04f0e0d6944b44e2f5f4cc92a
name: python-djangorestframework-xml
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: XML support for Django REST Framework
url: https://github.com/jpadilla/django-rest-framework-xml
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1e92f849-b54a-4fcd-94a8-ece1e079a89d
location_href: 00011662-python-djangorestframework-xml/python-djangorestframework-xml-2.0.0-1.src.rpm
checksum_type: sha256
description:
  [![build-status-image]][github-action]
  [![pypi-version]][pypi]

  **XML support for Django REST Framework**

  Full documentation for the project is available at [http://jpadilla.github.io/django-rest-framework-xml][docs].



  XML support extracted as a third party package directly from the official Django REST Framework implementation. It requires the [defusedxml][defusedxml] package only because it safeguards against some security issues that were discovered.

  **Note**: XML output provided is an ad-hoc format that isn't formally described. If you have specific XML requirements you'll need to write your own XML parsers/renderers in order to fully control the representation.



  * Python 3.5+
  * Django 2.2+
  * Django REST Framework 3.11+



  Install using `pip`...

  ```bash
  $ pip install djangorestframework-xml
  ```



  ```python
  REST_FRAMEWORK = {
      'DEFAULT_PARSER_CLASSES': (
          'rest_framework_xml.parsers.XMLParser',
      ),
      'DEFAULT_RENDERER_CLASSES': (
          'rest_framework_xml.renderers.XMLRenderer',
      ),
  }
  ```

  You can also set the renderer and parser used for an individual view, or viewset, using the APIView class based views.

  ```python
  from rest_framework import routers, serializers, viewsets
  from rest_framework_xml.parsers import XMLParser
  from rest_framework_xml.renderers import XMLRenderer


  class UserSerializer(serializers.HyperlinkedModelSerializer):
      class Meta:
          model = User
          fields = ('url', 'username', 'email', 'is_staff')


  class UserViewSet(viewsets.ModelViewSet):
      queryset = User.objects.all()
      serializer_class = UserSerializer
      parser_classes = (XMLParser,)
      renderer_classes = (XMLRenderer,)
  ```



  ```xml
  <?xml version="1.0" encoding="utf-8"?>
  <root>
      <list-item>
          <url>http://127.0.0.1:8000/users/1/.xml</url>
          <username>jpadilla</username>
          <email>jpadilla@example.com</email>
          <is_staff>True</is_staff>
      </list-item>
  </root>
  ```



  Full documentation for the project is available at [http://jpadilla.github.io/django-rest-framework-xml][docs].

  You may also want to follow the [author][jpadilla] on Twitter.


  [build-status-image]: https://github.com/jpadilla/django-rest-framework-xml/workflows/CI/badge.svg
  [github-action]: https://github.com/jpadilla/django-rest-framework-xml/actions?query=workflow%3ACI
  [pypi-version]: https://img.shields.io/pypi/v/djangorestframework-xml.svg
  [pypi]: https://pypi.python.org/pypi/djangorestframework-xml
  [defusedxml]: https://pypi.python.org/pypi/defusedxml
  [docs]: http://jpadilla.github.io/django-rest-framework-xml
  [jpadilla]: https://twitter.com/jpadilla_


pkgId: 5f058eb96bcc25883a7b950a9167abb46c995e2f7e61ed4ce81a3bcbb7cb688e
name: python-djangosaml2
arch: src
version: 1.5.6
epoch: 0
release: 1
summary: pysaml2 integration for Django
url: https://github.com/IdentityPython/djangosaml2
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4db1975b-6268-4c28-8e0a-f13a04934d35
location_href: 00012581-python-djangosaml2/python-djangosaml2-1.5.6-1.src.rpm
checksum_type: sha256
description:
  ![CI build](https://github.com/peppelinux/djangosaml2/workflows/djangosaml2/badge.svg)
  ![pypi](https://img.shields.io/pypi/v/djangosaml2.svg)
  [![Downloads](https://pepy.tech/badge/djangosaml2/month)](https://pepy.tech/project/djangosaml2)
  ![Python version](https://img.shields.io/badge/license-Apache%202-blue.svg)
  ![Django versions](https://img.shields.io/pypi/djversions/djangosaml2)
  ![Documentation Status](https://readthedocs.org/projects/djangosaml2/badge/?version=latest)
  ![License](https://img.shields.io/badge/python-3.7%20%7C%203.8%20%7C%203.9%20%7C%203.10-blue.svg)
  A Django application that builds a Fully Compliant SAML2 Service Provider on top of PySAML2 library.
   Djangosaml2 protects your project with a SAML2 SSO Authentication.
  Features:
  - HTTP-REDIRECT SSO Binding
  - HTTP-POST SSO Binding
  - SLO POST and HTTP-REDIRECT Binding
  - Discovery Service
  - embedded Wayf page with customizable html template
  - IdP Hinting
  - IdP Scoping
  - Samesite cookie
  Please consult the [official Documentation of djangosaml2](https://djangosaml2.readthedocs.io) to get started.


pkgId: 562531055e776d012a46b4783a7cd997fcc5659e1d4f1dd8737880ed81adfddb
name: python-djangosaml2idp
arch: src
version: 0.7.2
epoch: 0
release: 1
summary: SAML 2.0 Identity Provider for Django
url: https://github.com/OTA-Insight/djangosaml2idp/
rpm_license: Apache Software License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a742d710-a459-4d19-bdb1-5a04d0261b24
location_href: 00012062-python-djangosaml2idp/python-djangosaml2idp-0.7.2-1.src.rpm
checksum_type: sha256
description:
  djangosaml2idp implements the Identity Provider side of the SAML2 protocol for Django.
  It builds on top of `PySAML2 <https://github.com/IdentityPython/pysaml2>`_, and is production-ready.
  Any contributions, feature requests, proposals, ideas ... are welcome! See the `CONTRIBUTING document <https://github.com/OTA-Insight/djangosaml2idp/blob/master/CONTRIBUTING.md>`_ for some info.


pkgId: 876648fa5ac46321e41bf74ba45814ea6940635bd3d1f8f0bb7263d9b0a98680
name: python-djongo
arch: src
version: 1.3.6
epoch: 0
release: 1
summary: Driver for allowing Django to use MongoDB as the database backend.
url: https://nesdis.github.io/djongo/
rpm_license: AGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e1818fbc-fbaf-4d96-80e9-f5364d05c68b
location_href: 00014261-python-djongo/python-djongo-1.3.6-1.src.rpm
checksum_type: sha256
description:
  1. Install djongo::
        pip install djongo
  2. Into settings.py file of your project, add::
        DATABASES = {
             'default': {
                 'ENGINE': 'djongo',
                 'NAME': 'your-db-name',
             }
         }
  3. Run (ONLY the first time to create collections in mongoDB)::
        manage.py makemigrations
        manage.py migrate
  YOUR ARE SET! HAVE FUN!


pkgId: f2742194d341ed5958275a35beba76df50e95899b461e241a18c3485d6d882e0
name: python-dlipower
arch: src
version: 1.0.176
epoch: 0
release: 1
summary: Control digital loggers web power switch
url: https://github.com/dwighthubbard/python-dlipower/
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-80d9511f-93a7-4e60-835e-b3d872d70ecf
location_href: 00010695-python-dlipower/python-dlipower-1.0.176-1.src.rpm
checksum_type: sha256
description:
  This is a python module and a script to mange the
  Digital Loggers Web Power switch.
  The module provides a python class named
  PowerSwitch that allows managing the web power
  switch from python programs.
  When run as a script this acts as a command
  line utility to manage the DLI Power switch.


pkgId: b903009c32b21c31a32cba77b7db1174605254c9de3465cd9c4f9b854a6abf74
name: python-dlx
arch: src
version: 1.0.4
epoch: 0
release: 1
summary: Implementation of Donald Knuth's Dancing Links algorithm.
url: http://www.site.uottawa.ca/~mraap046
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2f935313-be8f-43c2-b062-73a198eaac59
location_href: 00013713-python-dlx/python-dlx-1.0.4-1.src.rpm
checksum_type: sha256
description:
  This package provides an implementation of Donald Knuth's Dancing
           Links algorithm for solving exact set cover problems.

           1.0.4: Minor Python 3 bugfix.
           1.0.3: Attempt to make code compatible with Python 3.
           1.0.2: Removed extraneous code (had switched from callbacks for solutions to
                  making solve a generator to yield, but had forgotten to remove the
                  solution callback function parameter from the solve method).
           1.0.1: Critical bugfix (N array was one short: did not account for header).
           1.0.0: Initial release.


pkgId: 4c3c00355e6e7b0b05dde46d158b68e459e9272f89995ad3893e2d2fcc234a9c
name: python-dm-haiku
arch: src
version: 0.0.9
epoch: 0
release: 1
summary: Haiku is a library for building neural networks in JAX.
url: https://github.com/deepmind/dm-haiku
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5ca0f8e0-b915-41ac-92ee-e92698cfe1d4
location_href: 00012004-python-dm-haiku/python-dm-haiku-0.0.9-1.src.rpm
checksum_type: sha256
description:
  [**Overview**](#overview)
  | [**Why Haiku?**](#why-haiku)
  | [**Quickstart**](#quickstart)
  | [**Installation**](#installation)
  | [**Examples**](https://github.com/deepmind/dm-haiku/tree/main/examples/)
  | [**User manual**](#user-manual)
  | [**Documentation**](https://dm-haiku.readthedocs.io/)
  | [**Citing Haiku**](#citing-haiku)

  ![pytest](https://github.com/deepmind/dm-haiku/workflows/pytest/badge.svg)
  ![docs](https://readthedocs.org/projects/dm-haiku/badge/?version=latest)
  ![pypi](https://img.shields.io/pypi/v/dm-haiku)



  > Haiku is a tool<br>
  > For building neural networks<br>
  > Think: "[Sonnet] for [JAX]"

  Haiku is a simple neural network library for [JAX] developed by some of the
  authors of [Sonnet], a neural network library for [TensorFlow].

  Documentation on Haiku can be found at https://dm-haiku.readthedocs.io/.

  **Disambiguation:** if you are looking for Haiku the operating system then
  please see https://haiku-os.org/.



  [JAX] is a numerical computing library that combines NumPy, automatic
  differentiation, and first-class GPU/TPU support.

  Haiku is a simple neural network library for JAX that enables users to use
  familiar **object-oriented programming models** while allowing full access to
  JAX's pure function transformations.

  Haiku provides two core tools: a module abstraction, `hk.Module`, and a simple
  function transformation, `hk.transform`.

  `hk.Module`s are Python objects that hold references to their own parameters,
  other modules, and methods that apply functions on user inputs.

  `hk.transform` turns functions that use these object-oriented, functionally
  "impure" modules into pure functions that can be used with `jax.jit`,
  `jax.grad`, `jax.pmap`, etc.



  There are a number of neural network libraries for JAX. Why should you choose
  Haiku?



  - DeepMind has reproduced a number of experiments in Haiku and JAX with relative
    ease. These include large-scale results in image and language processing,
    generative models, and reinforcement learning.



  - Haiku is designed to make specific things simpler: managing model parameters
    and other model state.
  - Haiku can be expected to compose with other libraries and work well with the
    rest of JAX.
  - Haiku otherwise is designed to get out of your way - it does not define custom
    optimizers, checkpointing formats, or replication APIs.



  - Haiku builds on the programming model and APIs of Sonnet, a neural network
    library with near universal adoption at DeepMind. It preserves Sonnet's
    `Module`-based programming model for state management while retaining access
    to JAX's function transformations.
  - Haiku APIs and abstractions are as close as reasonable to Sonnet. Many users
    have found Sonnet to be a productive programming model in TensorFlow; Haiku
    enables the same experience in JAX.



  - By design, transitioning from TensorFlow and Sonnet to JAX and Haiku is easy.
  - Outside of new features (e.g. `hk.transform`), Haiku aims to match the API of
    Sonnet 2. Modules, methods, argument names, defaults, and initialization
    schemes should match.



  - Haiku offers a trivial model for working with random numbers. Within a
    transformed function, `hk.next_rng_key()` returns a unique rng key.
  - These unique keys are deterministically derived from an initial random key
    passed into the top-level transformed function, and are thus safe to use with
    JAX program transformations.



  Let's take a look at an example neural network, loss function, and training
  loop. (For more examples, see our
  [examples directory](https://github.com/deepmind/dm-haiku/tree/main/examples/).
  The
  [MNIST example](https://github.com/deepmind/dm-haiku/tree/main/examples/mnist.py)
  is a good place to start.)

  ```python
  import haiku as hk
  import jax.numpy as jnp

  def softmax_cross_entropy(logits, labels):
    one_hot = jax.nn.one_hot(labels, logits.shape[-1])
    return -jnp.sum(jax.nn.log_softmax(logits) * one_hot, axis=-1)

  def loss_fn(images, labels):
    mlp = hk.Sequential([
        hk.Linear(300), jax.nn.relu,
        hk.Linear(100), jax.nn.relu,
        hk.Linear(10),
    ])
    logits = mlp(images)
    return jnp.mean(softmax_cross_entropy(logits, labels))

  loss_fn_t = hk.transform(loss_fn)
  loss_fn_t = hk.without_apply_rng(loss_fn_t)

  rng = jax.random.PRNGKey(42)
  dummy_images, dummy_labels = next(input_dataset)
  params = loss_fn_t.init(rng, dummy_images, dummy_labels)

  def update_rule(param, update):
    return param - 0.01 * update

  for images, labels in input_dataset:
    grads = jax.grad(loss_fn_t.apply)(params, images, labels)
    params = jax.tree_util.tree_map(update_rule, params, grads)
  ```

  The core of Haiku is `hk.transform`. The `transform` function allows you to
  write neural network functions that rely on parameters (here the weights of the
  `Linear` layers) without requiring you to explicitly write the boilerplate
  for initialising those parameters. `transform` does this by transforming the
  function into a pair of functions that are _pure_ (as required by JAX) `init`
  and `apply`.



  The `init` function, with signature `params = init(rng, ...)` (where `...` are
  the arguments to the untransformed function), allows you to **collect** the
  initial value of any parameters in the network. Haiku does this by running your
  function, keeping track of any parameters requested through `hk.get_parameter`
  (called by e.g. `hk.Linear`) and returning them to you.

  The `params` object returned is a nested data structure of all the
  parameters in your network, designed for you to inspect and manipulate.
  Concretely, it is a mapping of module name to module parameters, where a module
  parameter is a mapping of parameter name to parameter value. For example:

  ```
  {'linear': {'b': ndarray(..., shape=(300,), dtype=float32),
              'w': ndarray(..., shape=(28, 300), dtype=float32)},
   'linear_1': {'b': ndarray(..., shape=(100,), dtype=float32),
                'w': ndarray(..., shape=(1000, 100), dtype=float32)},
   'linear_2': {'b': ndarray(..., shape=(10,), dtype=float32),
                'w': ndarray(..., shape=(100, 10), dtype=float32)}}
  ```



  The `apply` function, with signature `result = apply(params, rng, ...)`, allows
  you to **inject** parameter values into your function. Whenever
  `hk.get_parameter` is called, the value returned will come from the `params` you
  provide as input to `apply`:

  ```python
  loss = loss_fn_t.apply(params, rng, images, labels)
  ```

  Note that since the actual computation performed by our loss function doesn't
  rely on random numbers, passing in a random number generator is unnecessary, so
  we could also pass in `None` for the `rng` argument. (Note that if your
  computation _does_ use random numbers, passing in `None` for `rng` will cause
  an error to be raised.) In our example above, we ask Haiku to do this for us
  automatically with:

  ```python
  loss_fn_t = hk.without_apply_rng(loss_fn_t)
  ```

  Since `apply` is a pure function we can pass it to `jax.grad` (or any of JAX's
  other transforms):

  ```python
  grads = jax.grad(loss_fn_t.apply)(params, images, labels)
  ```



  The training loop in this example is very simple. One detail to note is the use
  of `jax.tree_util.tree_map` to apply the `sgd` function across all matching
  entries in `params` and `grads`. The result has the same structure as the
  previous `params` and can again be used with `apply`.




  Haiku is written in pure Python, but depends on C++ code via JAX.

  Because JAX installation is different depending on your CUDA version, Haiku does
  not list JAX as a dependency in `requirements.txt`.

  First, follow [these instructions](https://github.com/google/jax#installation)
  to install JAX with the relevant accelerator support.

  Then, install Haiku using pip:

  ```bash
  $ pip install git+https://github.com/deepmind/dm-haiku
  ```

  Alternatively, you can install via PyPI:

  ```bash
  $ pip install -U dm-haiku
  ```

  Our examples rely on additional libraries (e.g. [bsuite](https://github.com/deepmind/bsuite)). You can install the full set of additional requirements using pip:

  ```bash
  $ pip install -r examples/requirements.txt
  ```





  In Haiku, all modules are a subclass of `hk.Module`. You can implement any
  method you like (nothing is special-cased), but typically modules implement
  `__init__` and `__call__`.

  Let's work through implementing a linear layer:

  ```python
  class MyLinear(hk.Module):

    def __init__(self, output_size, name=None):
      super().__init__(name=name)
      self.output_size = output_size

    def __call__(self, x):
      j, k = x.shape[-1], self.output_size
      w_init = hk.initializers.TruncatedNormal(1. / np.sqrt(j))
      w = hk.get_parameter("w", shape=[j, k], dtype=x.dtype, init=w_init)
      b = hk.get_parameter("b", shape=[k], dtype=x.dtype, init=jnp.zeros)
      return jnp.dot(x, w) + b
  ```

  All modules have a name. When no `name` argument is passed to the module, its
  name is inferred from the name of the Python class (for example `MyLinear`
  becomes `my_linear`). Modules can have named parameters that are accessed
  using `hk.get_parameter(param_name, ...)`. We use this API (rather than just
  using object properties) so that we can convert your code into a pure function
  using `hk.transform`.

  When using modules you need to define functions and transform them into a pair
  of pure functions using `hk.transform`. See our [quickstart](#quickstart) for
  more details about the functions returned from `transform`:

  ```python
  def forward_fn(x):
    model = MyLinear(10)
    return model(x)




  forward = hk.transform(forward_fn)

  x = jnp.ones([1, 1])




  key = hk.PRNGSequence(42)
  params = forward.init(next(key), x)






  y = forward.apply(params, None, x)
  ```



  Some models may require random sampling as part of the computation.
  For example, in variational autoencoders with the reparametrization trick,
  a random sample from the standard normal distribution is needed. For dropout we
  need a random mask to drop units from the input. The main hurdle in making this
  work with JAX is in management of PRNG keys.

  In Haiku we provide a simple API for maintaining a PRNG key sequence associated
  with modules: `hk.next_rng_key()` (or `next_rng_keys()` for multiple keys):

  ```python
  class MyDropout(hk.Module):

    def __init__(self, rate=0.5, name=None):
      super().__init__(name=name)
      self.rate = rate

    def __call__(self, x):
      key = hk.next_rng_key()
      p = jax.random.bernoulli(key, 1.0 - self.rate, shape=x.shape)
      return x * p / (1.0 - self.rate)

  forward = hk.transform(lambda x: MyDropout()(x))

  key1, key2 = jax.random.split(jax.random.PRNGKey(42), 2)
  params = forward.init(key1, x)
  prediction = forward.apply(params, key2, x)
  ```

  For a more complete look at working with stochastic models, please see our
  [VAE example](https://github.com/deepmind/dm-haiku/tree/main/examples/vae.py).

  **Note:** `hk.next_rng_key()` is not functionally pure which means you should
  avoid using it alongside JAX transformations which are inside `hk.transform`.
  For more information and possible workarounds, please consult the docs on
  [Haiku transforms](https://dm-haiku.readthedocs.io/en/latest/notebooks/transforms.html)
  and available
  [wrappers for JAX transforms inside Haiku networks](https://dm-haiku.readthedocs.io/en/latest/api.html#haiku-transforms).



  Some models may want to maintain some internal, mutable state. For example, in
  batch normalization a moving average of values encountered during training is
  maintained.

  In Haiku we provide a simple API for maintaining mutable state that is
  associated with modules: `hk.set_state` and `hk.get_state`. When using these
  functions you need to transform your function using `hk.transform_with_state`
  since the signature of the returned pair of functions is different:

  ```python
  def forward(x, is_training):
    net = hk.nets.ResNet50(1000)
    return net(x, is_training)

  forward = hk.transform_with_state(forward)




  params, state = forward.init(rng, x, is_training=True)




  logits, state = forward.apply(params, state, rng, x, is_training=True)
  ```

  If you forget to use `hk.transform_with_state` don't worry, we will print a
  clear error pointing you to `hk.transform_with_state` rather than silently
  dropping your state.



  The pure functions returned from `hk.transform` (or `hk.transform_with_state`)
  are fully compatible with `jax.pmap`. For more details on SPMD programming with
  `jax.pmap`,
  [look here](https://jax.readthedocs.io/en/latest/jax.html#parallelization-pmap).

  One common use of `jax.pmap` with Haiku is for data-parallel training on many
  accelerators, potentially across multiple hosts. With Haiku, that might look
  like this:

  ```python
  def loss_fn(inputs, labels):
    logits = hk.nets.MLP([8, 4, 2])(x)
    return jnp.mean(softmax_cross_entropy(logits, labels))

  loss_fn_t = hk.transform(loss_fn)
  loss_fn_t = hk.without_apply_rng(loss_fn_t)


  rng = jax.random.PRNGKey(428)
  sample_image, sample_label = next(input_dataset)
  params = loss_fn_t.init(rng, sample_image, sample_label)


  num_devices = jax.local_device_count()
  params = jax.tree_util.tree_map(lambda x: np.stack([x] * num_devices), params)

  def make_superbatch():
    """Constructs a superbatch, i.e. one batch of data per device."""
    
    superbatch = [next(input_dataset) for _ in range(num_devices)]
    superbatch_images, superbatch_labels = zip(*superbatch)
    
    
    superbatch_images = np.stack(superbatch_images)
    superbatch_labels = np.stack(superbatch_labels)
    return superbatch_images, superbatch_labels

  def update(params, inputs, labels, axis_name='i'):
    """Updates params based on performance on inputs and labels."""
    grads = jax.grad(loss_fn_t.apply)(params, inputs, labels)
    
    grads = jax.lax.pmean(grads, axis_name)
    
    new_params = my_update_rule(params, grads)
    return new_params


  for _ in range(10):
    superbatch_images, superbatch_labels = make_superbatch()
    params = jax.pmap(update, axis_name='i')(params, superbatch_images,
                                             superbatch_labels)
  ```

  For a more complete look at distributed Haiku training, take a look at our
  [ResNet-50 on ImageNet example](https://github.com/deepmind/dm-haiku/tree/main/examples/imagenet/).



  To cite this repository:

  ```
  @software{haiku2020github,
    author = {Tom Hennigan and Trevor Cai and Tamara Norman and Igor Babuschkin},
    title = {{H}aiku: {S}onnet for {JAX}},
    url = {http://github.com/deepmind/dm-haiku},
    version = {0.0.9},
    year = {2020},
  }
  ```

  In this bibtex entry, the version number is intended to be from
  [`haiku/__init__.py`](https://github.com/deepmind/dm-haiku/blob/main/haiku/__init__.py),
  and the year corresponds to the project's open-source release.

  [JAX]: https://github.com/google/jax
  [Sonnet]: https://github.com/deepmind/sonnet
  [Tensorflow]: https://github.com/tensorflow/tensorflow


pkgId: 364de7dd16ddea0132f49b5c821fceaf793aad4d7192f39184966eb6ad508c9b
name: python-dnsgen
arch: src
version: 1.0.4
epoch: 0
release: 1
summary: Generates DNS possibilities from existing domain names.
url: https://github.com/me/myproject
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6a836b18-70cd-4ed7-8b4c-7e6cfb29bd3a
location_href: 00003525-python-dnsgen/python-dnsgen-1.0.4-1.src.rpm
checksum_type: sha256
description:
  This tool generates a combination of domain names from the provided input. Combinations are created based on wordlist. Custom words are extracted per execution. Refer to [Techniques](#techniques) section to learn more.

  `dnsgen` is very similar to [altdns](https://github.com/infosec-au/altdns). It does not contain DNS resolver. You should use [massdns](https://github.com/blechschmidt/massdns) for DNS resolution.

  ![dnsgen](https://0xpatrik.com/content/images/2019/09/dnsgen-1.png)



  ```pip3 install dnsgen```

  ..or from GitHub directly:

  ```
  git clone https://github.com/ProjectAnte/dnsgen
  cd dnsgen
  pip3 install -r requirements.txt
  python3 setup.py install
  ```



  ```$ dnsgen domains.txt``` (`domains.txt` contains a list of active domain names)

  * `-l` / `--wordlen`: minimum size of custom words to be extracted
  * `-w` / `--wordlist`: path to custom wordlist
  * `-f` / `--fast`: Generate lower amount of domains with most probable words only
  * `filename`: required parameter for an input list of domains. The input file should contain domain names separated by newline character (`\n`). You can also use STDIN as an input method, providing `-` to this argument.

  **Combination with massdns:**

  `$ cat domains.txt | dnsgen - | massdns -r /path/to/resolvers.txt -t A -o J --flush 2>/dev/null`



  *(For demo purposes, let's say that wordlist contains just one word: `stage`)*

  * **Insert word on every index** — Creates new subdomain levels by inserting the words between existing levels. `foo.example.com` -> `stage.foo.example.com`, `foo.stage.example.com`

  * **Increase/Decrease num found** — *(In development)* If number is found in an existing subdomain, increase/decrease this number without any other alteration. `foo01.example.com` -> `foo02.example.com`, `foo03.example.com`, `...`

  * **Prepend word on every index** — On every subdomain level, prepend existing content with `WORD` and `WORD-`. `foo.example.com` -> `stagefoo.example.com`, `stage-foo.example.com`

  * **Append word on every index** — On every subdomain level, append existing content with `WORD` and `WORD-`. `foo.example.com` -> `foostage.example.com`, `foo-stage.example.com`

  * **Replace the word with word** — If word longer than 3 is found in an existing subdomain, replace it with other words from the wordlist. *(If we have more words than one in our wordlist)*. `stage.foo.example.com` -> `otherword.foo.example.com`, `anotherword.foo.example.com`, `...`

  * **Extract custom words** — Extend the wordlist based on target's domain naming conventions. Such words are either whole subdomain levels, or `-` is used for a split on some subdomain level. For instance `mapp1-current.datastream.example.com` has `mapp1`, `current`, `datastream` words. To prevent the overflow, user-defined *word length* is used for word extraction. The default value is set to **6**. This means that only words strictly longer than **5** characters are included (from the previous example, `mapp1` does not satisfy this condition).



  - [Subdomain Enumeration: 2019 Workflow](https://0xpatrik.com/subdomain-enumeration-2019/)
  - [Subdomain Enumeration: Doing it a Bit Smarter](https://0xpatrik.com/subdomain-enumeration-smarter/)



  - Improve README
  - Tests


pkgId: 9d010344164f54a38138a9d955121801e28822ded01dedbfe279f8ac4345d955
name: python-dnslib
arch: src
version: 0.9.23
epoch: 0
release: 1
summary: Simple library to encode/decode DNS wire-format packets
url: https://github.com/paulc/dnslib
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b4b5d68c-93d8-4251-880a-25a673434468
location_href: 00003526-python-dnslib/python-dnslib-0.9.23-1.src.rpm
checksum_type: sha256
description:
  A library to encode/decode DNS wire-format packets supporting both
  Python 2.7 and Python 3.2+.
  The library provides:
   * Support for encoding/decoding DNS packets between wire format,
     python objects, and Zone/DiG textual representation (dnslib.dns)
   * A server framework allowing the simple creation of custom DNS
     resolvers (dnslib.server) and a number of example servers
     created using this framework
   * A number of utilities for testing (dnslib.client, dnslib.proxy,
     dnslib.intercept)
  Python 3 support was added in Version 0.9.0 which represented a fairly
  major update to the library - the key changes include:
   * Python 2.7/3.2+ support (the last version supporting Python 2.6
     or earlier was version 0.8.3)
   * The 'Bimap' interface was changed significantly to explicitly
     split forward (value->text) lookups via __getitem__ and
     reverse (text->value) lookups via __getattr__. Applications
     using the old interface will need to be updated.
   * Hostnames are now returned with a trailing dot by default (in
     line with RFC)
   * Most object attributes are now typed in line with the record
     definitions to make it harder to generate invalid packets
   * Support for encoding/decoding resource records in 'Zone' (BIND)
     file format
   * Support for encoding/decoding packets in 'DiG' format
   * Server framework allowing (in most cases) custom resolvers to
     be created by just subclassing the DNSResolver class and
     overriding the 'resolve' method
   * A lot of fixes to error detection/handling which should make
     the library much more robust to invalid/unsupported data. The
     library should now either return a valid DNSRecord instance
     when parsing a packet or raise DNSError (tested via fuzzing)
   * Improved utilities (dnslib.client, dnslib.proxy, dnslib.intercept)
   * Improvements to encoding/decoding tests including the ability
     to generate test data automatically in test_decode.py (comparing
     outputs against DiG)
   * Ability to compare and diff DNSRecords


pkgId: 2e9b164a1f94d4fcfbf6d489c2431b26a44d77633123acba059966c8845372fc
name: python-dnspython
arch: src
version: 2.3.0
epoch: 0
release: 1
summary: DNS toolkit
url: https://www.dnspython.org
rpm_license: ISC
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5d4344ac-bef5-476e-a787-5c917474b4e4
location_href: 00009059-python-dnspython/python-dnspython-2.3.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://github.com/rthalley/dnspython/actions/workflows/python-package.yml/badge.svg)](https://github.com/rthalley/dnspython/actions/)
  [![Documentation Status](https://readthedocs.org/projects/dnspython/badge/?version=latest)](https://dnspython.readthedocs.io/en/latest/?badge=latest)
  [![PyPI version](https://badge.fury.io/py/dnspython.svg)](https://badge.fury.io/py/dnspython)
  [![License: ISC](https://img.shields.io/badge/License-ISC-brightgreen.svg)](https://opensource.org/licenses/ISC)
  [![Coverage](https://codecov.io/github/rthalley/dnspython/coverage.svg?branch=master)](https://codecov.io/github/rthalley/dnspython)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)



  dnspython is a DNS toolkit for Python. It supports almost all record types. It
  can be used for queries, zone transfers, and dynamic updates. It supports TSIG
  authenticated messages and EDNS0.

  dnspython provides both high and low level access to DNS. The high level classes
  perform queries for data of a given name, type, and class, and return an answer
  set. The low level classes allow direct manipulation of DNS zones, messages,
  names, and records.

  To see a few of the ways dnspython can be used, look in the `examples/`
  directory.

  dnspython is a utility to work with DNS, `/etc/hosts` is thus not used. For
  simple forward DNS lookups, it's better to use `socket.getaddrinfo()` or
  `socket.gethostbyname()`.

  dnspython originated at Nominum where it was developed
  to facilitate the testing of DNS software.



  This is dnspython 2.3.0.
  Please read
  [What's New](https://dnspython.readthedocs.io/en/stable/whatsnew.html) for
  information about the changes in this release.



  * Many distributions have dnspython packaged for you, so you should
    check there first.
  * If you have pip installed, you can do `pip install dnspython`
  * If not just download the source file and unzip it, then run
    `sudo python setup.py install`
  * To install the latest from the master branch, run `pip install git+https://github.com/rthalley/dnspython.git`

  Dnspython's default installation does not depend on any modules other than
  those in the Python standard library.  To use some features, additional modules
  must be installed.  For convenience, pip options are defined for the
  requirements.

  If you want to use DNS-over-HTTPS, run
  `pip install dnspython[doh]`.

  If you want to use DNSSEC functionality, run
  `pip install dnspython[dnssec]`.

  If you want to use internationalized domain names (IDNA)
  functionality, you must run
  `pip install dnspython[idna]`

  If you want to use the Trio asynchronous I/O package, run
  `pip install dnspython[trio]`.

  If you want to use the Curio asynchronous I/O package, run
  `pip install dnspython[curio]`.

  If you want to use WMI on Windows to determine the active DNS settings
  instead of the default registry scanning method, run
  `pip install dnspython[wmi]`.

  If you want to try the experimental DNS-over-QUIC code, run
  `pip install dnspython[doq]`.

  Note that you can install any combination of the above, e.g.:
  `pip install dnspython[doh,dnssec,idna]`



  Python 2.x support ended with the release of 1.16.0.  Dnspython 2.0.0 through
  2.2.x support Python 3.6 and later.  As of dnspython 2.3.0, the minimum
  supported Python version will be 3.7.  We plan to align future support with the
  lifetime of the Python 3 versions.

  Documentation has moved to
  [dnspython.readthedocs.io](https://dnspython.readthedocs.io).


pkgId: 0ea8bd1455bb14835578880fae9b64257ba0cffd1e0bb7d1aec1dd5306787161
name: python-dnspython3
arch: src
version: 1.15.0
epoch: 0
release: 1
summary: A DNS toolkit for Python 3.x
url: http://www.dnspython.org
rpm_license: http://www.dnspython.org/LICENSE
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c0f2e6b8-b710-48b0-94a3-c18a3d23cc90
location_href: 00011537-python-dnspython3/python-dnspython3-1.15.0-1.src.rpm
checksum_type: sha256
description:
  dnspython3 has been superseded by the regular dnspython kit, which now
  supports both Python 2 and Python 3.

  Installing this kit will simply cause the regular dnspython kit to be installed as a dependency.


pkgId: 209fe34979241f166e9fa17f7e78e4c4ac7d631be3e5cd3bb80aa6a68dd3ff38
name: python-doc-warden
arch: src
version: 0.7.2
epoch: 0
release: 1
url: https://github.com/Azure/azure-sdk-tools/
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6bdeecda-1c61-4bf9-ace4-50e4129602e6
location_href: 00011742-python-doc-warden/python-doc-warden-0.7.2-1.src.rpm
checksum_type: sha256
summary:
  Doc-Warden is an internal project created by the Azure SDK Team. It is intended to be used by CI Builds to ensure that documentation standards are met. See readme for more details.

description:
  Every CI build owned by the Azure-SDK team also needs to verify that the documentation within the target repo meets a set of standards. `Doc-warden` is intended to ease the _implementation_ of these checks in CI builds.

  Features:

  * Enforces Readme Standards
      - Readmes present
      - Readmes have appropriate content
  * Enforces Changelog Standards
      - Changelogs Present
      - Changelogs contain entry and content for the latest package version
  * Generates report for included observed packages

  This package is tested on Python 3.4 -> 3.8. This package went python3-only starting with `0.7.0`.


  This package is intended to be run as part of a pipeline within Azure DevOps. As such, [Python](https://www.python.org/downloads/) must be installed prior to attempting to install or use `Doc-Warden.` While `pip` comes pre-installed on most modern Python installs, if `pip` is an unrecognized command when attempting to install `warden`, run the following command **after** your Python installation is complete.

  In addition, `warden` is distributed using `setuptools` and `wheel`, so those packages should also be present prior to install.

  ```
  /:> python -m ensurepip
  /:> pip install setuptools wheel
  ```



  Right now, `warden` supports two main purposes. 1. Readme and Changelog enforcement (`scan`, `content`, `presence`), and 2. package indexing (`index`).



  ```

  <pre-step, clone target repository>
  ...
  /:> pip install setuptools wheel
  /:> pip install doc-warden
  ...
  <next task, because PATH doesn't update without another one>
  /:> ward scan -d $(Build.SourcesDirectory)

  ```
  **Notes for example above**

  * Assumption is that the `.docsettings` file is placed at the root of the repository.

  To provide a different path (like `azure-sdk-for-java` does...), use:

  ```

  /:> ward scan -d $(Build.SourcesDirectory) -c $(Build.SourcesDirectory)/eng/.docsettings.yml

  ```



  `command`
  Currently supports 3 commands. Values: `['scan', 'presence', 'content', `index`]` **Required.**

  * `scan`
      * Run both `content` and `presence` enforcement on the targeted directory.
  * `content`
      * Run only `content` enforcement on the target directory. Ensures that:
        - The content in each readme matches the regex patterns defined in the .docsettings file
        - Each changelog contains entry for the latest version.
  * `presence`
      * Run only `presence` enforcement on the target directory. Ensures readmes and changelogs exist where they should.
  * `index`
      * Take inventory of the target folder. Attempts to leverage selected docsettings to discover all packages within the directory, and generate a `packages.md` index file.

  `--scan-directory`
  The target directory `warden` should be scanning. **Required.**

  `--repo-root`
  The root of the repo. Entries in the config-file should be relative to this directory. **Optional.**

  `--scan-language`
  `warden` checks for packages by _convention_, so it needs to understand what language it is looking at. This must be populated either in `.docsettings file` or by parameter. **Optional.**

  `--config-location`
  By default, `warden` looks for the `.docsettings` file in the root of the repository. However, populating this location will override this behavior and instead pull the file from the location in this parameter. **Optional.**

  `--pipeline-stage`
  The stage of the pipeline. can be `pr`, `ci`, or `release`. **Optional.**

  `--target`
  Specify what file to run enforcement on `readme` or `changelog`. Used when running `content` or `presence` verification only. **Optional.**

  `--package-output`
  Override the default location that the generated `packages.md` file is dropped to during execution of the `index` command.

  `--verbose-output`
  Enable or disable output of an html report. Defaults to false. **Optional.**



  The `-d` argument should be `$(Build.SourcesDirectory)`. This will point `warden` at the repo that has been associated with CI.





  When should we expect a readme and/or changelog to be present?

  **Always:**

  * At the root of the repo (Readme only)
  * Associated with a `package` directory (Readme and Changelog)



  A package directory is indicated by:

  * a `*,csproj` file under the `sdk` directory
      * Note that this is just a proxy. `warden` attempts to omit test projects by convention.




  A package directory is indicated by:

  * the presence of a `setup.py` file



  A package directory is indicated by:

  * the presence of a `pom.xml` file
      * The POM `<packaging>` value within is set to `JAR`



  A package directory is indicated by:

  * The presence of a `package.json` file



  `doc-warden` has the ability to check discovered readme files to ensure that a set of configured sections is present. How does it work? `doc-warden` will ensure that each regex defined in `required_readme_sections` matches against at least one section header in the readme. If all the patterns match at least one header, the readme will pass content verification.

  Other Notes:

  * A `section` header is any markdown or RST that will result in a `<h1>` to `<h2>` html tag.
  * `warden` will content verify any `readme.rst` or `readme.md` file found outside the `omitted_paths` in the targeted repo.


  `doc-warden` checks the latest entry in the changelog file to make sure it matches the latest version of the package. It also checks to make sure that the entry is not empty.




  Special cases often need to be configured. It seems logical that there needs be a central location (per repo) to override conventional settings. To that end, a new `.docsettings.yml` file will be added to each repo.

  ```
  <repo-root>
  │   README.md
  │   .docsettings.yml
  │
  └───.azure-pipelines
  │   │   <build def>
  │
  └───<other files and folders>
  ```

  The presence of this file allows each repository to customize how enforcement takes place within their repo.

  **Example DocSettings File for Java Repo**

  ```
  omitted_paths:
    - archive/*
    - sdk/eventhub/
  language: java
  root_check_enabled: True
  required_readme_sections:
    - "(Client Library for Azure .*|Microsoft Azure SDK for .*)"
    - Getting Started
      - Install Package
      - Prerequisites
      - Authenticate the Client
  known_presence_issues:
    - ['cognitiveservices/data-plane/language/bingspellcheck/README.md', '#2847']
    - ['cognitiveservices/data-plane/language/bingspellcheck/CHANGELOG.md', '#2847']
  known_content_issues:
    - ['sdk/template/azure-sdk-template/README.md','#1368']
    - ['sdk/template/azure-sdk-template/CHANGELOG.md','#1368']
  ```
  The above configuration tells `warden`...

  - The language within the repo is `java`
  - To ensure that a `README.md` is present at the root of the repository.
  - To omit **any** paths under `archive/` from the readme checks.
  - To omit paths found **directly** under `sdk/eventhub/`.
     - This means that if there is a readme content issue under `sdk/eventhub/azure-messaging/`, it will still throw an error!

  Possible values for `language` right now are `['net', 'java', 'js', 'python']`. Greater than one target language is not currently supported.


  This section instructs `warden` to verify that there is at least one matching section title for each provided `section` pattern in any discovered readme. Notice that **nested** specifications are supported. Regex is fully supported.

  The two items listed from the example `.docsettings` file will:

  - Match a header matched by a simple regex expression
  - Match a header exactly titled "Getting Started"
        - Under the header "Getting Started" validate that 3 additional headings are present.
        - `doc-warden` will search up to the next header of equivalent importantance for the sub-headings.
          - This means that when searching under header `# Getting Started`, doc-warden will scan up to the next `H1` header.

  Note that the regex is surrounded by quotation marks where the regex will break `yml` parsing of the configuration file.


  `doc-warden` is designed to crash builds if it detects failures. However, the vast majority of the time, these issues cannot be fixed immediately. In the above configuration, there are two paths highlighted as known issues.

  The first, `known_presence_issues`, tells warden that a presence failure detected at the specified paths _should be ignored_ and should not result in a crashed build. A `tuple` describing each known issue specifies both what the known issue is, as well as some sort of justification. Having an exception with an issueId attached is a good justification for not failing the build.

  > We're aware of this issue, and it is tracked in the following github issue.

  The `known_content_issues` parameter functions _identically_ to the `known_presence_issues` check. If a readme is listed as "already known" to have failures, the entire CI build will not be crashed by Warden.


  Indexing packages is often done as part of nightly (or triggered) automation. With this being the case, sometimes `warden` may detect a PackageId that users wish to omit from the generated `packages.md` file. The Azure SDK team leverages
  the `package_indexing_exclusion_list` array members to enable just this sort of scenario.

  `package_indexing_traversal_stops` is used during parse of .NET language repos _only_. This is due to how the discovery logic for readme and changelog is implemented for .NET projects. Specifically, readmes for a .csproj are often a couple directories up from their parent .csproj location!

  For .net, `warden` will traverse **up** one directory at a time, looking for the readme and changelog files in each traversed directory. `warden` will continue to traverse until...

  1. It discovers a folder with a `.sln` within it
  2. It encounters a folder that exactly matches one present in `package_indexing_traversal_stops`

  Note that `warden` will not even execute an index against a .NET repo _unless the traversal stops are set_.

  [SDK for net .docsettings](https://github.com/Azure/azure-sdk-for-net/blob/main/eng/.docsettings.yml) is a great example for both the exclusion list as well as the traversal stops.



  If you encounter any bugs or have suggestions, please file an issue [here](https://github.com/Azure/azure-sdk-tools/issues) and assign to `scbedd`.


pkgId: 60c04a7b2bcd25482926cf6863d311d10389250dad29660b070cbcb305dc2b17
name: python-docker
arch: src
version: 6.0.1
epoch: 0
release: 1
summary: A Python library for the Docker Engine API.
url: https://github.com/docker/docker-py
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7666237d-9215-48d2-8dac-1d83a2dd88d0
location_href: 00008942-python-docker/python-docker-6.0.1-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://github.com/docker/docker-py/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/docker/docker-py/actions/workflows/ci.yml/)

  A Python library for the Docker Engine API. It lets you do anything the `docker` command does, but from within Python apps – run containers, manage containers, manage Swarms, etc.



  The latest stable version [is available on PyPI](https://pypi.python.org/pypi/docker/). Either add `docker` to your `requirements.txt` file or install with pip:

      pip install docker

  > Older versions (< 6.0) required installing `docker[tls]` for SSL/TLS support.
  > This is no longer necessary and is a no-op, but is supported for backwards compatibility.



  Connect to Docker using the default socket or the configuration in your environment:

  ```python
  import docker
  client = docker.from_env()
  ```

  You can run containers:

  ```python
  >>> client.containers.run("ubuntu:latest", "echo hello world")
  'hello world\n'
  ```

  You can run containers in the background:

  ```python
  >>> client.containers.run("bfirsh/reticulate-splines", detach=True)
  <Container '45e6d2de7c54'>
  ```

  You can manage containers:

  ```python
  >>> client.containers.list()
  [<Container '45e6d2de7c54'>, <Container 'db18e4f20eaa'>, ...]

  >>> container = client.containers.get('45e6d2de7c54')

  >>> container.attrs['Config']['Image']
  "bfirsh/reticulate-splines"

  >>> container.logs()
  "Reticulating spline 1...\n"

  >>> container.stop()
  ```

  You can stream logs:

  ```python
  >>> for line in container.logs(stream=True):
  ...   print(line.strip())
  Reticulating spline 2...
  Reticulating spline 3...
  ...
  ```

  You can manage images:

  ```python
  >>> client.images.pull('nginx')
  <Image 'nginx'>

  >>> client.images.list()
  [<Image 'ubuntu'>, <Image 'nginx'>, ...]
  ```

  [Read the full documentation](https://docker-py.readthedocs.io) to see everything you can do.


pkgId: 2a472567e0e5439c024c7fae1ec59f57d0b26d6d0796895037aee42a2f9ee636
name: python-docker-py
arch: src
version: 1.10.6
epoch: 0
release: 1
summary: Python client for Docker.
url: https://github.com/docker/docker-py/
rpm_license: UNKNOWN
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-3f05994b-0011-4a27-adda-178d1d203ed0
location_href: 00010774-python-docker-py/python-docker-py-1.10.6-1.src.rpm
checksum_type: sha256
description:
  |Build Status|
  A Python library for the Docker Remote API. It does everything the
  ``docker`` command does, but from within Python – run containers, manage
  them, pull/push images, etc.


pkgId: c66ad8f657a86f0355020e548e72d2d6f6310e57a3712547f2ec57c53a555ad6
name: python-docker-pycreds
arch: src
version: 0.4.0
epoch: 0
release: 1
summary: Python bindings for the docker credentials store API
url: https://github.com/shin-/dockerpy-creds
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-0c652825-c95e-4178-b3a6-5506428b6b13
location_href: 00009402-python-docker-pycreds/python-docker-pycreds-0.4.0-1.src.rpm
checksum_type: sha256
description:
  [![CircleCI](https://circleci.com/gh/shin-/dockerpy-creds/tree/master.svg?style=svg)](https://circleci.com/gh/shin-/dockerpy-creds/tree/master)

  Python bindings for the docker credentials store API



  [Docker documentation page](https://docs.docker.com/engine/reference/commandline/login/#/credentials-store)



  On top of the dependencies in `requirements.txt`, the `docker-credential`
  executable for the platform must be installed on the user's system.



  ```python

  import dockerpycreds

  store = dockerpycreds.Store('secretservice')
  store.store(
      server='https://index.docker.io/v1/', username='johndoe',
      secret='hunter2'
  )

  print(store.list())

  print(store.get('https://index.docker.io/v1/'))


  store.erase('https://index.docker.io/v1/')
  ```


pkgId: 54ff643879088df3355ac5fd37bfce445576818132760931a42916b3c2364b7b
name: python-dockerfile-parse
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: Python library for Dockerfile manipulation
url: https://github.com/containerbuildsystem/dockerfile-parse
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-91c8b5f2-69fc-46ab-8295-af868fc4373d
location_href: 00003529-python-dockerfile-parse/python-dockerfile-parse-2.0.0-1.src.rpm
checksum_type: sha256
description:
  [![unittests status badge]][unittests status link]
  [![coveralls status badge]][coveralls status link]
  [![lgtm python badge]][lgtm python link]
  [![lgtm alerts badge]][lgtm alerts link]
  [![linters status badge]][linters status link]

  Python library for parsing Dockerfile files.





  ```shell
  pip install dockerfile-parse
  ```



  Clone this git repo and install using the python installer

  ```shell
  git clone https://github.com/containerbuildsystem/dockerfile-parse.git
  cd dockerfile-parse
  sudo pip install .
  ```



  ```python
  from pprint import pprint
  from dockerfile_parse import DockerfileParser

  dfp = DockerfileParser()
  dfp.content = """\
  From  base
  LABEL foo="bar baz"
  USER  me"""


  pprint(dfp.structure)
  pprint(dfp.json)
  pprint(dfp.labels)


  dfp.baseimage = 'centos:7'


  print(dfp.content)
  ```

  [coveralls status badge]: https://coveralls.io/repos/containerbuildsystem/dockerfile-parse/badge.svg?branch=master
  [coveralls status link]: https://coveralls.io/r/containerbuildsystem/dockerfile-parse?branch=master
  [lgtm python badge]: https://img.shields.io/lgtm/grade/python/g/containerbuildsystem/dockerfile-parse.svg?logo=lgtm&logoWidth=18
  [lgtm python link]: https://lgtm.com/projects/g/containerbuildsystem/dockerfile-parse/context:python
  [lgtm alerts badge]: https://img.shields.io/lgtm/alerts/g/containerbuildsystem/dockerfile-parse.svg?logo=lgtm&logoWidth=18
  [lgtm alerts link]: https://lgtm.com/projects/g/containerbuildsystem/dockerfile-parse/alerts
  [linters status badge]: https://github.com/containerbuildsystem/dockerfile-parse/workflows/Linters/badge.svg?branch=master&event=push
  [linters status link]: https://github.com/containerbuildsystem/dockerfile-parse/actions?query=event%3Apush+branch%3Amaster+workflow%3A%22Linters%22
  [unittests status badge]: https://github.com/containerbuildsystem/dockerfile-parse/workflows/Unittests/badge.svg?branch=master&event=push
  [unittests status link]: https://github.com/containerbuildsystem/dockerfile-parse/actions?query=event%3Apush+branch%3Amaster+workflow%3A%22Unittests%22


pkgId: a6f4fcb1d37b75140ca88605b288ada3fc96f934f6b42b5f79a0eb69d8c68fdf
name: python-dockerpty
arch: src
version: 0.4.1
epoch: 0
release: 1
summary: Python library to use the pseudo-tty of a docker container
url: https://github.com/d11wtq/dockerpty
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bbe8877d-d5eb-477e-a146-161198ccde6b
location_href: 00009453-python-dockerpty/python-dockerpty-0.4.1-1.src.rpm
checksum_type: sha256
description:
  Provides the functionality needed to operate the pseudo-tty (PTY) allocated to
  a docker container, using the Python client.

  [![Build Status](https://travis-ci.org/d11wtq/dockerpty.svg?branch=master)]
  (https://travis-ci.org/d11wtq/dockerpty)



  Via pip:

  ```
  pip install dockerpty
  ```

  Dependencies:

    * docker-py>=0.3.2

  However, this library does not explicitly declare this dependency in PyPi for a
  number of reasons. It is assumed you have it installed.



  The following example will run busybox in a docker container and place the user
  at the shell prompt via Python.

  This obviously only works when run in a terminal.

  ``` python
  import docker
  import dockerpty

  client = docker.Client()
  container = client.create_container(
      image='busybox:latest',
      stdin_open=True,
      tty=True,
      command='/bin/sh',
  )

  dockerpty.start(client, container)
  ```

  Keyword arguments passed to `start()` will be forwarded onto the client to
  start the container.

  When the dockerpty is started, control is yielded to the container's PTY until
  the container exits, or the container's PTY is closed.

  This is a safe operation and all resources are restored back to their original
  states.

  > **Note:** dockerpty does support attaching to non-tty containers to stream
  container output, though it is obviously not possible to 'control' the
  container if you do not allocate a pseudo-tty.

  If you press `C-p C-q`, the container's PTY will be closed, but the container
  will keep running. In other words, you will have detached from the container
  and can re-attach with another `dockerpty.start()` call.



  If you want to hack on dockerpty and send a PR, you'll need to run the tests.
  In the features/ directory, are features/user stories for how dockerpty is
  supposed to work. To run them:

  ```
  -bash$ pip install -r requirements-dev.txt
  -bash$ behave features/
  ```

  You'll need to have docker installed and running locally. The tests use busybox
  container as a test fixture, so are not too heavy.

  Step definitions are defined in features/steps/.

  There are also unit tests for the parts of the code that are not inherently
  dependent on controlling a TTY. To run those:

  ```
  -bash$ pip install -r requirements-dev.txt
  -bash$ py.test tests/
  ```

  Travis CI runs this build inside a UML kernel that is new enough to run docker.
  Your PR will need to pass the build before I can merge it.

    - Travis CI build: https://travis-ci.org/d11wtq/dockerpty



  In a terminal, the three file descriptors stdin, stdout and stderr are all
  connected to the controlling terminal (TTY). When you pass the `tty=True` flag
  to docker's `create_container()`, docker allocates a fake TTY inside the
  container (a PTY) to which the container's stdin, stdout and stderr are all
  connected.

  The docker API provides a way to access the three sockets connected to the PTY.
  If with access to the host system's TTY file descriptors and the container's
  PTY file descriptors, it is trivial to simply 'pipe' data written to these file
  descriptors between the host and the container. Doing this makes the user's
  terminal effectively become the pseudo-terminal from inside the container.

  In reality it's a bit more complicated than this, since care must be taken to
  put the host terminal into raw mode (where keys such as enter are not
  interpreted with any special meaning) and restore it on exit. Additionally, the
  container's stdout and stderr streams along with `sys.stdin` must be made
  non-blocking so that they can be used with `select()` without blocking the main
  process. These attributes are restored on exit.

  The size of a terminal cannot be controlled by sending data to stdin and can
  only be controlled by the terminal program itself. Since the pseudo-terminal is
  running inside a real terminal, it is import that the size of the PTY be kept
  the same as that of the presenting TTY. For this reason, docker provides an API
  call to resize the allocated PTY. A SIGWINCH handler is used to detect window
  size changes and resize the pseudo-terminal as needed.



    - Primary author: [Chris Corbyn](https://github.com/d11wtq)
    - Collaborator: [Daniel Nephin](https://github.com/dnephin)
    - Contributor: [Stephen Moore](https://github.com/delfick)
    - Contributor: [Ben Firshman](https://github.com/bfirsh)



  Copyright &copy; 2014 Chris Corbyn. See the LICENSE.txt file for details.


pkgId: b75932c9e74c07a4d95ad35b15f2f66d2ec265dc6e2d159aa8f4ed6c564fd456
name: python-docutils
arch: src
version: 0.19
epoch: 0
release: 1
summary: Docutils -- Python Documentation Utilities
url: https://docutils.sourceforge.io/
rpm_license: public domain, Python, 2-Clause BSD, GPL 3 (see COPYING.txt)
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-0166c6a4-d405-4b19-9c12-36cddf1f6d6a
location_href: 00008908-python-docutils/python-docutils-0.19-1.src.rpm
checksum_type: sha256
description:
  Docutils is a modular system for processing documentation
  into useful formats, such as HTML, XML, and LaTeX.  For
  input Docutils supports reStructuredText, an easy-to-read,
  what-you-see-is-what-you-get plaintext markup syntax.


pkgId: 92061329dbdb9cd58dcfffb9f74351423a7acd4b5ffed46d4533a7604b538334
name: python-docx
arch: src
version: 0.2.4
epoch: 0
release: 1
summary: The docx module creates, reads and writes Microsoft Office Word 2007 docx files
url: http://github.com/mikemaccana/python-docx
rpm_license: UNKNOWN
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2a1c6cc6-1e7b-42de-bb90-bb9a565a9839
location_href: 00003531-python-docx/python-docx-0.2.4-1.src.rpm
checksum_type: sha256
description:
  The docx module creates, reads and writes Microsoft Office Word 2007 docx
  files.
  These are referred to as 'WordML', 'Office Open XML' and 'Open XML' by
  Microsoft.
  These documents can be opened in Microsoft Office 2007 / 2010, Microsoft Mac
  Office 2008, Google Docs, OpenOffice.org 3, and Apple iWork 08.
  They also `validate as well formed XML <http://validator.w3.org/check>`_.
  The module was created when I was looking for a Python support for MS Word
  .docx files, but could only find various hacks involving COM automation,
  calling .Net or Java, or automating OpenOffice or MS Office.
  The docx module has the following features:


pkgId: f383b251a7895c921cdc1f561e5d2f7043cefe814bee79b4a2a37fae540707be
name: python-dogpile.cache
arch: src
version: 1.1.8
epoch: 0
release: 1
summary: A caching front-end based on the Dogpile lock.
url: https://github.com/sqlalchemy/dogpile.cache
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e640c097-f920-4d35-8c70-ed47ac1644c1
location_href: 00003532-python-dogpile-cache/python-dogpile.cache-1.1.8-1.src.rpm
checksum_type: sha256
description:
  Dogpile consists of two subsystems, one building on top of the other.
  ``dogpile`` provides the concept of a "dogpile lock", a control structure
  which allows a single thread of execution to be selected as the "creator" of
  some resource, while allowing other threads of execution to refer to the previous
  version of this resource as the creation proceeds; if there is no previous
  version, then those threads block until the object is available.
  ``dogpile.cache`` is a caching API which provides a generic interface to
  caching backends of any variety, and additionally provides API hooks which
  integrate these cache backends with the locking mechanism of ``dogpile``.
  Overall, dogpile.cache is intended as a replacement to the `Beaker
  <https://pypi.org/project/Beaker/>`_ caching system, the internals of which are
  written by the same author.   All the ideas of Beaker which "work" are re-
  implemented in dogpile.cache in a more efficient and succinct manner, and all
  the cruft (Beaker's internals were first written in 2005) relegated to the
  trash heap.


pkgId: d67227cb4c8366ae0bb64207dc523bb5ef6b9c052c838e319a4715b2ec77866c
name: python-doit
arch: src
version: 0.36.0
epoch: 0
release: 1
summary: doit - Automation Tool
url: http://pydoit.org
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b7941cb8-04d1-43bd-90b3-362b1d8285d3
location_href: 00003534-python-doit/python-doit-0.36.0-1.src.rpm
checksum_type: sha256
description:
  Define functions returning python dict with task's meta-data.
  Snippet from `tutorial <http://pydoit.org/tutorial-1.html>`_:
    def task_imports():
        """find imports from a python module"""
        for name, module in PKG_MODULES.by_name.items():
            yield {
                'name': name,
                'file_dep': [module.path],
                'actions': [(get_imports, (PKG_MODULES, module.path))],
            }
    def task_dot():
        """generate a graphviz's dot graph from module imports"""
        return {
            'targets': ['requests.dot'],
            'actions': [module_to_dot],
            'getargs': {'imports': ('imports', 'modules')},
            'clean': True,
        }
    def task_draw():
        """generate image from a dot file"""
        return {
            'file_dep': ['requests.dot'],
            'targets': ['requests.png'],
            'actions': ['dot -Tpng s -o s'],
            'clean': True,
        }
  Run from terminal::
    $ doit list
    dot       generate a graphviz's dot graph from module imports
    draw      generate image from a dot file
    imports   find imports from a python module
    $ doit
    .  imports:requests.models
    .  imports:requests.__init__
    .  imports:requests.help
    (...)
    .  dot
    .  draw


pkgId: 4a9ea1a7e73488fcb77de30664bac224ee78dea18033f7d3241f550579d80bc4
name: python-dominate
arch: src
version: 2.7.0
epoch: 0
release: 1
summary: Dominate is a Python library for creating and manipulating HTML documents using an elegant DOM API.
url: https://github.com/Knio/dominate/
rpm_license: LGPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bae79e99-332c-4eb5-8b03-72882b05ab41
location_href: 00009893-python-dominate/python-dominate-2.7.0-1.src.rpm
checksum_type: sha256
description:
  `Dominate` is a Python library for creating and manipulating HTML documents using an elegant DOM API.
  It allows you to write HTML pages in pure Python very concisely, which eliminates the need to learn another template language, and lets you take advantage of the more powerful features of Python.
  ![Python version](https://img.shields.io/pypi/pyversions/dominate.svg?style=flat)
  [![Build status](https://img.shields.io/travis/Knio/dominate/master.svg?style=flat)](https://travis-ci.org/Knio/dominate)
  [![Coverage status](https://img.shields.io/coveralls/github/Knio/dominate/master.svg?style=flat)](https://coveralls.io/r/Knio/dominate?branch=master)
  Python:
  ```python
  import dominate
  from dominate.tags import *
  doc = dominate.document(title='Dominate your HTML')
  with doc.head:
      link(rel='stylesheet', href='style.css')
      script(type='text/javascript', src='script.js')
  with doc:
      with div(id='header').add(ol()):
          for i in ['home', 'about', 'contact']:
              li(a(i.title(), href='/%s.html' % i))
      with div():
          attr(cls='body')
          p('Lorem ipsum..')
  print(doc)
  ```
  Output:
  ```html
  <!DOCTYPE html>
  <html>
    <head>
      <title>Dominate your HTML</title>
      <link href="style.css" rel="stylesheet">
      <script src="script.js" type="text/javascript"></script>
    </head>
    <body>
      <div id="header">
        <ol>
          <li>
            <a href="/home.html">Home</a>
          </li>
          <li>
            <a href="/about.html">About</a>
          </li>
          <li>
            <a href="/contact.html">Contact</a>
          </li>
        </ol>
      </div>
      <div class="body">
        <p>Lorem ipsum..</p>
      </div>
    </body>
  </html>
  ```


pkgId: 7a67de5722795fcb731b6d4dae15a2e01bde13cdb4c5307edd8f710f7a234c4a
name: python-dotmap
arch: src
version: 1.3.30
epoch: 0
release: 1
summary: ordered, dynamically-expandable dot-access dictionary
url: https://github.com/drgrib/dotmap
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-dc391bf8-51c0-43ce-9a69-7ed9c14871b0
location_href: 00010423-python-dotmap/python-dotmap-1.3.30-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.com/drgrib/dotmap.svg?branch=master)](https://travis-ci.com/drgrib/dotmap)

  [![Donate](https://img.shields.io/badge/Donate-PayPal-green.svg)](https://www.paypal.com/donate?business=N2GLXLS5KBFBY&item_name=Chris+Redford&currency_code=USD)



  ```
  pip3 install dotmap
  ```



  Get updates for current installation

  ```
  pip3 install --upgrade dotmap
  ```



  `DotMap` is a dot-access `dict` subclass that

  -   has dynamic hierarchy creation (autovivification)
  -   can be initialized with keys
  -   easily initializes from `dict`
  -   easily converts to `dict`
  -   is ordered by insertion

  The key feature is exactly what you want: dot-access

  ```python
  from dotmap import DotMap
  m = DotMap()
  m.name = 'Joe'
  print('Hello ' + m.name)

  ```

  However, `DotMap` is a `dict` and you can treat it like a `dict` as needed

  ```python
  print(m['name'])

  m.name += ' Smith'
  m['name'] += ' Jr'
  print(m.name)

  ```

  It also has fast, automatic hierarchy (which can be deactivated by initializing with `DotMap(_dynamic=False)`)

  ```python
  m = DotMap()
  m.people.steve.age = 31
  ```

  And key initialization

  ```python
  m = DotMap(a=1, b=2)
  ```

  You can initialize it from `dict` and convert it to `dict`

  ```python
  d = {'a':1, 'b':2}

  m = DotMap(d)
  print(m)


  print(m.toDict())

  ```

  And it has iteration that is ordered by insertion

  ```python
  m = DotMap()

  m.people.john.age = 32
  m.people.john.job = 'programmer'
  m.people.mary.age = 24
  m.people.mary.job = 'designer'
  m.people.dave.age = 55
  m.people.dave.job = 'manager'

  for k, v in m.people.items():
  	print(k, v)
  print




  ```

  It also has automatic counter initialization

  ```python
  m = DotMap()
  for i in range(7):
  	m.counter += 1
  print(m.counter)

  ```

  And automatic addition initializations of any other type

  ```python
  m = DotMap()
  m.quote += 'lions'
  m.quote += ' and tigers'
  m.quote += ' and bears'
  m.quote += ', oh my'
  print(m.quote)

  ```

  There is also built-in `pprint` as `dict` or `json` for debugging a large `DotMap`

  ```python
  m.pprint()



  m.pprint(pformat='json')
















  ```

  And many other features involving dots and dictionaries that will be immediately intuitive when used.


pkgId: 7a11ac97d629223a2d7d7d2a0f98674ef41f94c99df1b0493362726ab565f941
name: python-dowhy
arch: src
version: 0.9.1
epoch: 0
release: 1
url: https://github.com/py-why/dowhy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-24014066-9985-4c4c-8d7f-d12cc96a52da
location_href: 00013359-python-dowhy/python-dowhy-0.9.1-1.src.rpm
checksum_type: sha256
summary:
  DoWhy is a Python library for causal inference that supports explicit modeling and testing of causal assumptions

description:
    Introducing DoWhy and the 4 steps of causal inference | `Microsoft Research Blog <https://www.microsoft.com/en-us/research/blog/dowhy-a-library-for-causal-inference/>`_ | `Video Tutorial <https://note.microsoft.com/MSR-Webinar-DoWhy-Library-Registration-On-Demand.html>`_ | `Arxiv Paper <https://arxiv.org/abs/2011.04216>`_ | `Arxiv Paper (GCM-extension) <https://arxiv.org/abs/2206.06821>`_ | `Slides <https://www2.slideshare.net/AmitSharma315/dowhy-an-endtoend-library-for-causal-inference>`_
    Read the `docs <https://py-why.github.io/dowhy/>`_ | Try it online! |Binder|_
  **Case Studies using DoWhy**: `Hotel booking cancellations <https://towardsdatascience.com/beyond-predictive-models-the-causal-story-behind-hotel-booking-cancellations-d29e8558cbaf>`_ | `Effect of customer loyalty programs <https://github.com/microsoft/dowhy/blob/main/docs/source/example_notebooks/dowhy_example_effect_of_memberrewards_program.ipynb>`_ | `Optimizing article headlines <https://medium.com/@akelleh/introducing-the-do-sampler-for-causal-inference-a3296ea9e78d>`_ | `Effect of home visits on infant health (IHDP) <https://towardsdatascience.com/implementing-causal-inference-a-key-step-towards-agi-de2cde8ea599>`_ | `Causes of customer churn/attrition <https://medium.com/geekculture/a-quickstart-for-causal-analysis-decision-making-with-dowhy-2ce2d4d1efa9>`_
  As computing systems are more frequently and more actively intervening in societally critical domains such as healthcare, education, and governance, it is critical to correctly predict and understand the causal effects of these interventions. Without an A/B test, conventional machine learning methods, built on pattern recognition and correlational analyses, are insufficient for decision-making.
  Much like machine learning libraries have done for prediction, **"DoWhy" is a Python library that aims to spark causal thinking and analysis**. DoWhy provides a principled four-step interface for causal inference that focuses on explicitly modeling causal assumptions and validating them as much as possible. The key feature of DoWhy is its state-of-the-art refutation API that can automatically test causal assumptions for any estimation method, thus making inference more robust and accessible to non-experts. DoWhy supports estimation of the average causal effect for backdoor, frontdoor, instrumental variable and other identification methods, and estimation of the conditional effect (CATE) through an integration with the EconML library.
  For a quick introduction to causal inference, check out `amit-sharma/causal-inference-tutorial <https://github.com/amit-sharma/causal-inference-tutorial/>`_. We also gave a more comprehensive tutorial at the ACM Knowledge Discovery and Data Mining (`KDD 2018 <http://www.kdd.org/kdd2018/>`_) conference: `causalinference.gitlab.io/kdd-tutorial <http://causalinference.gitlab.io/kdd-tutorial/>`_. For an introduction to the four steps of causal inference and its implications for machine learning, you can access this video tutorial from Microsoft Research: `DoWhy Webinar <https://note.microsoft.com/MSR-Webinar-DoWhy-Library-Registration-On-Demand.html>`_.
  Documentation for DoWhy is available at `py-why.github.io/dowhy <https://py-why.github.io/dowhy/>`_.


pkgId: ceed612ca188fb3849663132612beca46bb5d268d99843c4bca9c8c0defce2b3
name: python-dpath
arch: src
version: 2.1.4
epoch: 0
release: 1
summary: Filesystem-like pathing and searching for dictionaries
url: https://github.com/dpath-maintainers/dpath-python
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-79600e08-e07e-4631-9460-6bd59ae825f8
location_href: 00003539-python-dpath/python-dpath-2.1.4-1.src.rpm
checksum_type: sha256
description:
  |PyPI|
  |Python Version|
  |Build Status|
  |Gitter|
  A python library for accessing and searching dictionaries via
  /slashed/paths ala xpath
  Basically it lets you glob over a dictionary as if it were a filesystem.
  It allows you to specify globs (ala the bash eglob syntax, through some
  advanced fnmatch.fnmatch magic) to access dictionary elements, and
  provides some facility for filtering those results.
  sdists are available on pypi: http://pypi.python.org/pypi/dpath


pkgId: e977773237c0321c6171f177bd094ea9fcaaf97e29fb9f0c0347cbf9d663766c
name: python-dpkt
arch: src
version: 1.9.8
epoch: 0
release: 1
summary: fast, simple packet creation / parsing, with definitions for the basic TCP/IP protocols
url: https://github.com/kbandla/dpkt
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-025eb968-c219-4515-ab46-9d30b9b5650d
location_href: 00003540-python-dpkt/python-dpkt-1.9.8-1.src.rpm
checksum_type: sha256
description:
  ![Python package](https://github.com/kbandla/dpkt/workflows/Python%20package/badge.svg)
  [![Coverage Status](https://coveralls.io/repos/github/kbandla/dpkt/badge.svg?branch=master)](https://coveralls.io/github/kbandla/dpkt?branch=master)
  [![supported-versions](https://img.shields.io/pypi/pyversions/dpkt.svg)](https://pypi.python.org/pypi/dpkt)
  [![supported-versions](https://img.shields.io/pypi/implementation/dpkt.svg)](https://pypi.python.org/pypi/dpkt)

  The dpkt project is a python module for fast, simple packet parsing, with definitions for the basic TCP/IP protocols.


  ```
  pip install dpkt
  ```


  - [Main Docs for DPKT](https://kbandla.github.io/dpkt)


pkgId: 025906c36d9d00bd822c0167944b6db17b5fb29e6bb6238ee21f975293e539a7
name: python-dput
arch: src
version: 1.6
epoch: 0
release: 1
summary: dput-ng -- like dput, but better
url: UNKNOWN
rpm_license: GPL-2+
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-0748225f-fda8-430a-abd7-eacc709094df
location_href: 00003541-python-dput/python-dput-1.6-1.src.rpm
checksum_type: sha256
description:
  dput-ng is a from-scratch refresh of the old `dput(1)` command. This tool is
  used (at some point) to aid with the act of uploading a package to an archive.
  dput-ng aims to be compatible with the old `dput(1)` config files, while
  adding additional features for better sanity checking, and designed in an
  extensible way.
  Check the [docs](http://dput.rtfd.org) for more on topics that might
  interest you.


pkgId: f322b61a53080462ec443d5982bc4d7626f01ae8e096ae4422b6fa07318f739a
name: python-drat
arch: src
version: 1.0.3
epoch: 0
release: 1
summary: A reading text analysis tool
url: https://github.com/riverrun/drat
rpm_license: GPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f9c78faf-3d2a-4dcd-8b44-d0f319ac946f
location_href: 00003542-python-drat/python-drat-1.0.3-1.src.rpm
checksum_type: sha256
description:
  Text (readability) analysis tool written in Python (2.7 and 3).
  Features
  ~~~~~~~~
  Drat is a tool that analyzes reading texts and produces a brief report
  which provides the following information:
  - the Dale-Chall readability score.
  - the Coleman-Liau Readability Index.
  - the number of uncommon words (based on the General Service List).
  - a list of all of these uncommon words (if you choose the verbose option).
  Drat supports **docx**, **odt**, **ods**, **odp** files as well as text
  files and urls.
  You can also analyze multiple texts / links by creating a text file
  with the filenames / links written in it.
  A simple example of how drat can be used in a web application is provided in the
  webapp directory.
  Use
  ~~~
  Please read the `wiki <https://github.com/riverrun/drat/wiki>`_ for information about how to use drat.
  Dependencies
  ~~~~~~~~~~~~
  Python (2.7 or 3), click and requests.
  Name
  ~~~~
  Drat is a recursive acronym which either stands for Drat is a Readability
  Analysis Tool or Drat is a Rabid Assessor of Texts.
  Author
  ~~~~~~
  This program has been developed by David Whitlock.
  License
  ~~~~~~~
  Drat is free software: you can redistribute it and/or modify it under
  the terms of the GNU General Public License as published by the Free
  Software Foundation, either version 3 of the License, or (at your
  option) any later version.


pkgId: 7308c2e541f82cd64091945e81ad61aca6f8a5f0289f4afba301e9167bf2dcae
name: python-drf-compound-fields
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: Django-REST-framework serializer fields for compound types.
url: https://github.com/estebistec/drf-compound-fields
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-0df9830f-a4cc-49aa-9f14-deb04c991ea1
location_href: 00013838-python-drf-compound-fields/python-drf-compound-fields-2.0.0-1.src.rpm
checksum_type: sha256
description:
  `Django-REST-framework <http://www.django-rest-framework.org/>`_
  `serializer fields <http://www.django-rest-framework.org/api-guide/fields>`_ for compound types.
  Django-REST-framework provides the ability to
  `deal with multiple objects <http://www.django-rest-framework.org/api-guide/serializers#dealing-with-multiple-objects>`_
  using the `many=True` option on serializers. That allows for lists of objects and for fields to be
  lists of objects.
  This package expands on that and provides fields allowing:
  * Lists of simple (non-object) types, described by other serializer fields.
  * Fields that allow values to be a list or individual item of some type.
  * Dictionaries of simple and object types.
  * Partial dictionaries which include keys specified in a list.
  A quick example::
      from drf_compound_fields.fields import DictField
      from drf_compound_fields.fields import ListField
      from drf_compound_fields.fields import ListOrItemField
      from drf_compound_fields.fields import ListField
      from rest_framework import serializers
      class EmailContact(serializers.Serializer):
          email = serializers.EmailField()
          verified = serializers.BooleanField()
      class UserProfile(serializers.Serializer):
          username = serializers.CharField()
          email_contacts = EmailContact(many=True)  # List of objects: possible with REST-framework alone
          
          skills = ListField(serializers.CharField())  # E.g., ["javascript", "python", "ruby"]
          name = ListOrItemField(serializers.CharField())  # E.g., "Prince" or ["John", "Smith"]
          bookmarks = DictField(serializers.URLField())  # E.g., {"./": "http://slashdot.org"}
          measurements = PartialDictField(included_keys=['height', 'weight'], serializers.IntegerField())


pkgId: 68d32e5183deb7a31d4e2b2a30ce47e0d4f7bd42260d3467c2b94bcdf39ca2c2
name: python-drf-jwt
arch: src
version: 1.19.2
epoch: 0
release: 1
summary: JSON Web Token based authentication for Django REST framework
url: https://github.com/Styria-Digital/django-rest-framework-jwt
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-715653e8-6dd5-4d22-97f3-df3c27d34000
location_href: 00011377-python-drf-jwt/python-drf-jwt-1.19.2-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/Styria-Digital/django-rest-framework-jwt.svg?branch=master)](https://travis-ci.org/Styria-Digital/django-rest-framework-jwt)
  [![Coverage](https://codecov.io/github/Styria-Digital/django-rest-framework-jwt/branch/master/graph/badge.svg)](https://codecov.io/github/Styria-Digital/django-rest-framework-jwt/branch/master)

  JSON Web Token Authentication support for Django REST Framework



  This package provides [JSON Web Token Authentication][jwt-auth-spec] support
  for [Django REST framework][drf].

  If you want to know more about JWT, check out the following resources:

   - DjangoCon 2014 - JSON Web Tokens [Video][jwt-video] | [Slides][jwt-slides]
   - [Auth with JSON Web Tokens][auth-jwt]
   - [JWT.io][jwt-io]



  -  Python 2.7, 3.4+
  -  Django 1.11+
  -  Django REST Framework 3.7+



  ```bash
  $ pip install drf-jwt
  ```



  Full documentation for the project is available at [docs][docs].

  [jwt-auth-spec]: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
  [drf]: http://django-rest-framework.org/
  [jwt-video]: https://www.youtube.com/watch?v=825hodQ61bg
  [jwt-slides]: https://speakerdeck.com/jpadilla/djangocon-json-web-tokens
  [auth-jwt]: http://jpadilla.com/post/73791304724/auth-with-json-web-tokens
  [jwt-io]: http://jwt.io/
  [docs]: http://styria-digital.github.io/django-rest-framework-jwt


pkgId: 02ac2c77e08bb1b8244cadc687bc5900330bb0802d4e0332be4f3397abe48cbe
name: python-drf-nested-routers
arch: src
version: 0.93.4
epoch: 0
release: 1
summary: Nested resources for the Django Rest Framework
url: https://github.com/alanjds/drf-nested-routers
rpm_license: Apache
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c389b1cf-7cc7-435f-82eb-5cd6b3c64271
location_href: 00010337-python-drf-nested-routers/python-drf-nested-routers-0.93.4-1.src.rpm
checksum_type: sha256
description:
  **This is a work in progress. It "works for me" at www.apiregistro.com.br,
  but I cannot warranty that it fully "works everywhere" yet. Join us on Gitter (below) if you need some help.**



  [![Join the chat at https://gitter.im/alanjds/drf-nested-routers](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/alanjds/drf-nested-routers?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
  [![Build Status](https://github.com/alanjds/drf-nested-routers/workflows/CI/badge.svg)](https://github.com/alanjds/drf-nested-routers/actions?query=workflow%3ACI+branch%3Amaster)

  This package provides routers and fields to create nested resources in the [Django Rest Framework](http://django-rest-framework.org/)

  Nested resources are needed for full REST URL structure, if one resource lives inside another.

  The following example is about Domains and DNS Nameservers.
  There are many domains, and each domain has many nameservers. The "nameserver" resource does not
  exist without a domain, so you need it "nested" inside the domain.




  -  Python (3.6, 3.7, 3.8, 3.9)
  -  Django (2.2, 3.0, 3.1)
  -  Django REST Framework (3.11)

  It may work with lower versions, but since the release **0.92.1** is no more
  tested on CI for Pythons 2.7 to 3.5, Django 1.11 to 2.1 or DRF 3.6 to 3.10.




  You can install this library using pip:

  ```pip install drf-nested-routers```

  It is not needed to add this library in your Django project's `settings.py` file, as it does not contain any app, signal or model.



  The desired URL signatures are:
  ```
  /domain/ <- Domains list
  /domain/{pk}/ <- One domain, from {pk}
  /domain/{domain_pk}/nameservers/ <- Nameservers of domain from {domain_pk}
  /domain/{domain_pk}/nameservers/{pk} <- Specific nameserver from {pk}, of domain from {domain_pk}
  ```

  How to do it (example):
  ```python

  from rest_framework_nested import routers
  from views import DomainViewSet, NameserverViewSet
  (...)

  router = routers.SimpleRouter()
  router.register(r'domains', DomainViewSet)

  domains_router = routers.NestedSimpleRouter(router, r'domains', lookup='domain')
  domains_router.register(r'nameservers', NameserverViewSet, basename='domain-nameservers')



  urlpatterns = patterns('',
      url(r'^', include(router.urls)),
      url(r'^', include(domains_router.urls)),
  )
  ```

  ```python




  class NameserverViewSet(viewsets.ModelViewSet):
      def get_queryset(self):
          return Nameserver.objects.filter(domain=self.kwargs['domain_pk'])



  class NameserverViewSet(viewsets.ViewSet):
      def list(self, request, domain_pk=None):
          nameservers = self.queryset.filter(domain=domain_pk)
          (...)
          return Response([...])

      def retrieve(self, request, pk=None, domain_pk=None):
          nameservers = self.queryset.get(pk=pk, domain=domain_pk)
          (...)
          return Response(serializer.data)
  ```





  **(optional)** If you need hyperlinks for nested relations, you need a custom serializer.

  There you will inform how to access the *parent* of the instance being serialized when
  building the *children* URL.

  In the following example, an instance of Nameserver on `/domain/{domain_pk}/nameservers/{pk}`
  is being informed that the *parent* Domain should be looked up using the `domain_pk` kwarg
  from the URL:
  ```python


  from rest_framework_nested.relations import NestedHyperlinkedRelatedField

  class DomainSerializer(HyperlinkedModelSerializer):
      class Meta:
          model = Domain

      nameservers = HyperlinkedIdentityField(
          view_name='domain-nameservers-list',
          lookup_url_kwarg='domain_pk'
                          
                          
      )

  	

      nameservers = NestedHyperlinkedRelatedField(
          many=True,
          read_only=True,   # Or add a queryset
          view_name='domain-nameservers-detail',
          parent_lookup_kwargs={'domain_pk': 'domain__pk'}
                              
                              
      )
  ```

  **(optional)** If you want a little bit more control over the fields displayed for the nested relations while looking at the parent, you need a custom serializer using NestedHyperlinkedModelSerializer.
  ```python
  from rest_framework.serializers import HyperlinkedModelSerializer
  from rest_framework_nested.serializers import NestedHyperlinkedModelSerializer

  class NameserverSerializers(HyperlinkedModelSerializer):
  	class Meta:
  		model = Nameserver
  		fields = (...)


  class DomainNameserverSerializers(NestedHyperlinkedModelSerializer):
  	parent_lookup_kwargs = {
  		'domain_pk': 'domain__pk',
  	}
  	class Meta:
  		model = Nameserver
  		fields = ('url', ...)


  class DomainSerializer(HyperlinkedModelSerializer):
  	class Meta:
  		model = Domain
  		fields = (..., 'nameservers')

  	nameservers = DomainNameserverSerializers(many=True, read_only=True)
  ```



  Example of nested router 3 levels deep.
  You can use this same logic to nest routers as deep as you need.
  This example ahead accomplishes the below URL patterns.
  ```
  /clients/
  /clients/{pk}/
  /clients/{client_pk}/maildrops/
  /clients/{client_pk}/maildrops/{maildrop_pk}/
  /clients/{client_pk}/maildrops/{maildrop_pk}/recipients/
  /clients/{client_pk}/maildrops/{maildrop_pk}/recipients/{pk}/
  ```

  ```python

  router = DefaultRouter()
  router.register(r'clients', ClientViewSet, basename='clients')




  client_router = routers.NestedSimpleRouter(router, r'clients', lookup='client')
  client_router.register(r'maildrops', MailDropViewSet, basename='maildrops')




  maildrops_router = routers.NestedSimpleRouter(client_router, r'maildrops', lookup='maildrop')
  maildrops_router.register(r'recipients', MailRecipientViewSet, basename='recipients')




  urlpatterns = patterns (
      '',
      url(r'^', include(router.urls)),
      url(r'^', include(client_router.urls)),
      url(r'^', include(maildrops_router.urls)),
  )
  ```

  ```python

  class ClientViewSet(viewsets.ViewSet):
      serializer_class = ClientSerializer

      def list(self, request,):
          queryset = Client.objects.filter()
          serializer = ClientSerializer(queryset, many=True)
          return Response(serializer.data)

      def retrieve(self, request, pk=None):
          queryset = Client.objects.filter()
          client = get_object_or_404(queryset, pk=pk)
          serializer = ClientSerializer(client)
          return Response(serializer.data)


  class MailDropViewSet(viewsets.ViewSet):
      serializer_class = MailDropSerializer

      def list(self, request, client_pk=None):
          queryset = MailDrop.objects.filter(client=client_pk)
          serializer = MailDropSerializer(queryset, many=True)
          return Response(serializer.data)

      def retrieve(self, request, pk=None, client_pk=None):
          queryset = MailDrop.objects.filter(pk=pk, client=client_pk)
          maildrop = get_object_or_404(queryset, pk=pk)
          serializer = MailDropSerializer(maildrop)
          return Response(serializer.data)


  class MailRecipientViewSet(viewsets.ViewSet):
      serializer_class = MailRecipientSerializer

      def list(self, request, client_pk=None, maildrop_pk=None):
          queryset = MailRecipient.objects.filter(mail_drop__client=client_pk, mail_drop=maildrop_pk)
          serializer = MailRecipientSerializer(queryset, many=True)
          return Response(serializer.data)

      def retrieve(self, request, pk=None, client_pk=None, maildrop_pk=None):
          queryset = MailRecipient.objects.filter(pk=pk, mail_drop=maildrop_pk, mail_drop__client=client_pk)
          maildrop = get_object_or_404(queryset, pk=pk)
          serializer = MailRecipientSerializer(maildrop)
          return Response(serializer.data)
  ```

  ```python

  class ClientSerializer(HyperlinkedModelSerializer):
      class Meta:
          model = Client
          fields = (...)


  class MailDropSerializer(NestedHyperlinkedModelSerializer):
      parent_lookup_kwargs = {
          'client_pk': 'client__pk',
      }
      class Meta:
          model = MailDrop
          fields = (...)


  class MailRecipientSerializer(NestedHyperlinkedModelSerializer):
      parent_lookup_kwargs = {
          'maildrop_pk': 'mail_drop__pk',
          'client_pk': 'mail_drop__client__pk',
      }
      class Meta:
          model = MailRecipient
          fields = (...)
  ```



  In order to get started with testing, you will need to install [tox](https://tox.readthedocs.io/en/latest/).
  Once installed, you can then run one environment locally, to speed up your development cycle:

  ```
  $ tox -e py39-django3.1-drf3.11
  ```

  Once you submit a pull request, your changes will be run against many environments with GitHub Actions named CI.




  This package is licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
  and can undestand more at http://choosealicense.com/licenses/apache/ on the
  sidebar notes.

  Apache Licence v2.0 is a MIT-like licence. This means, in plain English:
  - It's truly open source
  - You can use it as you wish, for money or not
  - You can sublicence it (change the licence!!)
  - This way, you can even use it on your closed-source project
  As long as:
  - You cannot use the authors name, logos, etc, to endorse a project
  - You keep the authors copyright notices where this code got used, even on your closed-source project
  (come on, even Microsoft kept BSD notices on Windows about its TCP/IP stack :P)


pkgId: d8467bf81c4fc3a2b92263c812ccb55069928acd4444c483d0ccc9c0b60ec164
name: python-dropbox
arch: src
version: 11.36.0
epoch: 0
release: 1
summary: Official Dropbox API Client
url: http://www.dropbox.com/developers
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-cab10b2c-f665-4581-926d-340208b05793
location_href: 00003545-python-dropbox/python-dropbox-11.36.0-1.src.rpm
checksum_type: sha256
description:
  Create an app via the `Developer Console`_.
  Install via `pip <https://pip.pypa.io/>`_:
      $ pip install dropbox
  Install from source:
      $ git clone git://github.com/dropbox/dropbox-sdk-python.git
      $ cd dropbox-sdk-python
      $ python setup.py install
  After installation, follow one of our `Examples`_ or read the documentation on `Read The Docs`_.
  You can also view our `OAuth Guide`_.


pkgId: bb10972564d4c6fd7afaac39bf4dd509464a8ac08c4c01aa701657264aefef53
name: python-dsnparse
arch: src
version: 0.2.0
epoch: 0
release: 1
summary: parse dsn urls
url: http://github.com/Jaymon/dsnparse
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2f831223-f0ac-4e25-8db2-7ebb015a3c91
location_href: 00013598-python-dsnparse/python-dsnparse-0.2.0-1.src.rpm
checksum_type: sha256
description:
  Parse [dsn connection url strings](http://en.wikipedia.org/wiki/Data_source_name). Responsible for parsing dsn strings in projects like [prom](https://github.com/jaymon/prom) and [morp](https://github.com/jaymon/morp).

  This is a generic version of [dj-database-url](https://github.com/kennethreitz/dj-database-url).

  So, now you can create dsns like this:

      scheme://user:pass@host:port/path?query=query_val#fragment

  For example, let's look at a prom dsn:

      prom.interface.postgres.Interface://testuser:testpw@localhost/testdb

  Now let's parse it:

  ```python
  import dsnparse

  dsn = "prom.interface.postgres.Interface://testuser:testpw@localhost:1234/testdb"
  r = dsnparse.parse(dsn)

  print(r.scheme) # prom.interface.postgres.Interface
  print(r.username) # testuser
  print(r.password) # testpw
  print(r.host) # localhost
  print(r.port) # 1234
  print(r.hostloc) # localhost:1234
  print(r.paths) # ['testdb']
  ```

  Also, dsnparse can easily use environment variables:

  ```python
  r = dsnparse.parse_environ('ENVIRONMENT_VARIABLE_NAME')
  ```

  I tried to keep the interface very similar to [urlparse](https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlparse) so it will feel familiar to use.




  By default, `dsnparse.parse(dsn)` returns a `ParseResult` instance, but that can be customized:

  ```python
  import dsnparse

  class MyResult(dsnparse.ParseResult):
      def configure(self):
          
          self.interface = self.scheme

  dsn = "Interface://testuser:testpw@localhost:1234/testdb"
  r = dsnparse.parse(dsn, parse_class=MyResult)
  print(isinstance(r, MyResult)) # True
  print(r.interface) # Interface
  ```




  Use pip:

      pip install dsnparse

  or use pip with github:

      pip install -U "git+https://github.com/Jaymon/dsnparse#egg=dsnparse"


pkgId: 76c7e13e6a1f2f06923cc01013f94e5f6c6dd9676dede0881e9e5422b4091a18
name: python-dtale
arch: src
version: 2.14.0
epoch: 0
release: 1
summary: Web Client for Visualizing Pandas Objects
url: https://github.com/man-group/dtale
rpm_license: LGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f69e2e66-2940-4af2-bd82-ee83bdc0516d
location_href: 00012328-python-dtale/python-dtale-2.14.0-1.src.rpm
checksum_type: sha256
description:
  |CircleCI| |PyPI Python Versions| |PyPI| |Conda| |ReadTheDocs| |codecov|
  |Downloads| |Open in VS Code|


pkgId: 499e97a79b2ade7a6437baec2bf11a2e4f27d931f72d3020bcd84f793d0bafc1
name: python-dtfabric
arch: src
version: 20221218
epoch: 0
release: 1
summary: Data type fabric (dtfabric)
url: https://github.com/libyal/dtfabric
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-15d69d8a-0161-4813-a982-aa81311b7fcb
location_href: 00003546-python-dtfabric/python-dtfabric-20221218-1.src.rpm
checksum_type: sha256
description:
  dtFabric, or data type fabric, is a project to manage data types and structures, as used in the libyal projects.


pkgId: 8dd0d66a710a45c026fdaa3f6df96743a1c7eb11d430facf4bb5e8cf00dd77c4
name: python-dtopt
arch: src
version: 0.1
epoch: 0
release: 1
summary: Add options to doctest examples while they are running
url: http://pypi.python.org/pypi/dtopt/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ae5ff861-e56a-4755-8f10-a18f51eb76e9
location_href: 00003547-python-dtopt/python-dtopt-0.1-1.src.rpm
checksum_type: sha256
description:
  When using the `doctest
  <http://python.org/doc/current/lib/module-doctest.html>`_ module it is often
  convenient to use the ELLIPSIS option, which allows you to use ``...`` as a
  wildcard.  But you either have to setup the test runner to use this option, or
  you must put ``#doctest: +ELLIPSIS`` on *every* example that uses this feature.

  ``dtopt`` lets you enable this option globally from within a doctest, by doing::

      >>> from dtopt import ELLIPSIS

  (The options ``NORMALIZE_WHITESPACE`` and ``COMPARE`` are also available)

  You can install this from `the subversion repository
  <http://svn.colorstudy.com/dtopt/trunk/#egg=dtopt-dev>`_ with ``easy_install
  dtopt==dev``.


pkgId: 815e28f0e2b19d67f12f7caddf5f7f4b403f781cbae353dc750ac763ffad9004
name: python-dtreeviz
arch: src
version: 2.2.0
epoch: 0
release: 1
url: https://github.com/parrt/dtreeviz
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-798857d0-4e1b-4e4a-b35b-f42be3e641c4
location_href: 00010897-python-dtreeviz/python-dtreeviz-2.2.0-1.src.rpm
checksum_type: sha256
summary:
  A Python 3 library for sci-kit learn, XGBoost, LightGBM, Spark, and TensorFlow decision tree visualization

description:
  A python library for decision tree visualization and model interpretation.  Decision trees are the fundamental building block of [gradient boosting machines](http://explained.ai/gradient-boosting/index.html) and [Random Forests](https://en.wikipedia.org/wiki/Random_forest)(tm), probably the two most popular machine learning models for structured data.  Visualizing decision trees is a tremendous aid when learning how these models work and when interpreting models. The visualizations are inspired by an educational animation by [R2D3](http://www.r2d3.us/); [A visual introduction to machine learning](http://www.r2d3.us/visual-intro-to-machine-learning-part-1/). Please see [How to visualize decision trees](http://explained.ai/decision-tree-viz/index.html) for deeper discussion of our decision tree visualization library and the visual design decisions we made.

  Currently dtreeviz supports: [scikit-learn](https://scikit-learn.org/stable), [XGBoost](https://xgboost.readthedocs.io/en/latest), [Spark MLlib](https://spark.apache.org/mllib/), [LightGBM](https://lightgbm.readthedocs.io/en/latest/), and [Tensorflow](https://www.tensorflow.org/decision_forests).  See [Installation instructions](README.md#Installation).


pkgId: f7c41c8592eea12525ddf6ba67c768a1dcbc14bcb86f671116d7f640105eb474
name: python-duecredit
arch: src
version: 0.9.2
epoch: 0
release: 1
summary: Publications (and donations) tracer
url: https://github.com/duecredit/duecredit
rpm_license: 2-clause BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1a85dddc-5f75-4020-824b-2532fc0c2702
location_href: 00003548-python-duecredit/python-duecredit-0.9.2-1.src.rpm
checksum_type: sha256
description:
      [1] Van Der Walt, S., Colbert, S.C. & Varoquaux, G., 2011. The NumPy array: a structure for efficient numerical computation. Computing in Science & Engineering, 13(2), pp.22–30.
      [2] Jones, E. et al., 2001. SciPy: Open source scientific tools for Python.
      [3] Sibson, R., 1973. SLINK: an optimally efficient algorithm for the single-link cluster method. The Computer Journal, 16(1), pp.30–34.
  Incremental runs of various software would keep enriching that file.
  Then you can use `duecredit summary` command to show that information
  again (stored in `.duecredit.p` file) or export it as a BibTeX file
  ready for reuse, e.g.:
      $> duecredit summary --format=bibtex
      @article{van2011numpy,
              title={The NumPy array: a structure for efficient numerical computation},
              author={Van Der Walt, Stefan and Colbert, S Chris and Varoquaux, Gael},
              journal={Computing in Science \& Engineering},
              volume={13},
              number={2},
              pages={22--30},
              year={2011},
              publisher={AIP Publishing}
              }
      @Misc{JOP+01,
            author =    {Eric Jones and Travis Oliphant and Pearu Peterson and others},
            title =     {{SciPy}: Open source scientific tools for {Python}},
            year =      {2001--},
            url = "http://www.scipy.org/",
            note = {[Online; accessed 2015-07-13]}
          }
      @article{sibson1973slink,
              title={SLINK: an optimally efficient algorithm for the single-link cluster method},
              author={Sibson, Robin},
              journal={The Computer Journal},
              volume={16},
              number={1},
              pages={30--34},
              year={1973},
              publisher={Br Computer Soc}
          }
  and if by default only references for "implementation" are listed, we
  can enable listing of references for other tags as well (e.g. "edu"
  depicting instructional materials -- textbooks etc. on the topic):
      $> DUECREDIT_REPORT_TAGS=* duecredit summary
      DueCredit Report:
      - Scientific tools library / numpy (v 1.10.4) [1]
      - Scientific tools library / scipy (v 0.14) [2]
        - Hierarchical clustering / scipy.cluster.hierarchy (v 0.14) [3, 4, 5, 6, 7, 8, 9]
        - Single linkage hierarchical clustering / scipy.cluster.hierarchy:linkage (v 0.14) [10, 11]
      2 packages cited
      1 module cited
      1 function cited


pkgId: ace31a635399d3f46f923ebc69b885daee3ad3aa59be5eaa081d02454019801b
name: python-duet
arch: src
version: 0.2.7
epoch: 0
release: 1
summary: A simple future-based async library for python.
url: http://github.com/google/duet
rpm_license: Apache 2
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f1b4e78f-a4e0-43d7-9fc0-aae815b20c9d
location_href: 00013291-python-duet/python-duet-0.2.7-1.src.rpm
checksum_type: sha256
description:
  A simple future-based async library for python

  Duet takes inspiration from the amazing [trio](https://trio.readthedocs.io/en/stable/)
  library and the [structured concurrency](https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/)
  approach to async programming that it uses.
  However, duet differs from trio in two major ways:

  - Instead of a full-blown implementation of asynchronous IO, duet relies  on the
    `Future` interface for parallelism, and provides a way to run async/await
    coroutines around those `Future`s. This is useful if you are using an API that
    returns futures, such as RPC libraries like gRPC. The standard `Future`
    interface does not implement `__await__` directly, so `Future` instances must
    be wrapped in `duet.AwaitableFuture`.

  - duet is re-entrant. At the top level, you run async code by calling
    `duet.run(foo)`. Inside `foo` suppose you call a function that has not yet
    been fully refactored to be asynchronous, but itself calls `duet.run(bar)`.
    Most async libraries, including `trio` and `asyncio`, will raise an exception
    if you try to "re-enter" the event loop in this way, but duet allows it. We
    have found that this can simplify the process of refactoring code to be
    asynchronous because you don't have to completely separate the sync and async
    parts of your codebase all at once.



  Install from pypi:

  ```
  pip install duet
  ```



  duet is not an official Google project.


pkgId: 6e1f673ada3c9f2f328d402b08e630ca1ca7e78a35bac3b51833bebed9c804e3
name: python-dukpy
arch: src
version: 0.3.0
epoch: 0
release: 1
summary: Simple JavaScript interpreter for Python
url: https://github.com/amol-/dukpy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-de08c7e1-53fe-481c-86cf-833588e0adcd
location_href: 00003549-python-dukpy/python-dukpy-0.3.0-1.src.rpm
checksum_type: sha256
description:
  DukPy is a simple javascript interpreter for Python built on top of
  duktape engine **without any external dependency**.
  It comes with a bunch of common transpilers built-in for convenience:
      - *CoffeeScript*
      - *BabelJS*
      - *TypeScript*
      - *JSX*
      - *LESS*


pkgId: f42e3d06b31624b1a62d99a9db5db9a905cdf5f2b523221f2da2608a0e06a2e0
name: python-dukpy-debuginfo
arch: x86_64
version: 0.3.0
epoch: 0
release: 1
summary: Debug information for package python-dukpy
url: https://github.com/amol-/dukpy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-de08c7e1-53fe-481c-86cf-833588e0adcd
rpm_sourcerpm: python-dukpy-0.3.0-1.src.rpm
location_href: 00003549-python-dukpy/python-dukpy-debuginfo-0.3.0-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-dukpy.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: f7568b71e9c5dc01271132528a8895fb72e87b098ce2654c95fec09ec26ff87a
name: python-dukpy-debugsource
arch: x86_64
version: 0.3.0
epoch: 0
release: 1
summary: Debug sources for package python-dukpy
url: https://github.com/amol-/dukpy
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-de08c7e1-53fe-481c-86cf-833588e0adcd
rpm_sourcerpm: python-dukpy-0.3.0-1.src.rpm
location_href: 00003549-python-dukpy/python-dukpy-debugsource-0.3.0-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-dukpy.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: ed9dd64e59808e36f545958313a24d29a13eef75f286157def0eb65e03c7b61c
name: python-dulwich
arch: src
version: 0.21.3
epoch: 0
release: 1
summary: Python Git Library
url: https://www.dulwich.io/
rpm_license: Apachev2 or later or GPLv2
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6444e0ef-2d01-4154-a153-30e7fe2eb99c
location_href: 00003550-python-dulwich/python-dulwich-0.21.3-1.src.rpm
checksum_type: sha256
description:
  This is the Dulwich project.
  It aims to provide an interface to git repos (both local and remote) that
  doesn't call out to git directly but instead uses pure Python.
  **Main website**: <https://www.dulwich.io/>
  **License**: Apache License, version 2 or GNU General Public License, version 2 or later.
  The project is named after the part of London that Mr. and Mrs. Git live in
  in the particular Monty Python sketch.


pkgId: d4a1633d164344ff99d4506bea939886a0b13e45456751b5c5961900b3996fe1
name: python-dulwich-debuginfo
arch: x86_64
version: 0.21.3
epoch: 0
release: 1
summary: Debug information for package python-dulwich
url: https://www.dulwich.io/
rpm_license: Apachev2 or later or GPLv2
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-6444e0ef-2d01-4154-a153-30e7fe2eb99c
rpm_sourcerpm: python-dulwich-0.21.3-1.src.rpm
location_href: 00003550-python-dulwich/python-dulwich-debuginfo-0.21.3-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-dulwich.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: ae49639620c83f5a01a6c0116d1aba1607e32148382f0c82f50b146b7decdde7
name: python-dulwich-debugsource
arch: x86_64
version: 0.21.3
epoch: 0
release: 1
summary: Debug sources for package python-dulwich
url: https://www.dulwich.io/
rpm_license: Apachev2 or later or GPLv2
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-6444e0ef-2d01-4154-a153-30e7fe2eb99c
rpm_sourcerpm: python-dulwich-0.21.3-1.src.rpm
location_href: 00003550-python-dulwich/python-dulwich-debugsource-0.21.3-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-dulwich.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: c94f99048c3ebc58c238c55cd88c3059f7abfdd19649b27324416df76e6910f2
name: python-dunamai
arch: src
version: 1.16.0
epoch: 0
release: 1
summary: Dynamic version generation
url: https://github.com/mtkennerly/dunamai
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1bc681c4-808d-4246-b367-0c4e9b73c30c
location_href: 00011395-python-dunamai/python-dunamai-1.16.0-1.src.rpm
checksum_type: sha256
description:
  Dunamai is a Python 3.5+ library and command line tool for producing dynamic,
  standards-compliant version strings, derived from tags in your version
  control system. This facilitates uniquely identifying nightly or per-commit
  builds in continuous integration and releasing new versions of your software
  simply by creating a tag.

  Dunamai is also available as a [GitHub Action](https://github.com/marketplace/actions/run-dunamai).


  * Version control system support:
    * [Git](https://git-scm.com) (2.7.0+ is recommended, but versions as old as 1.8.2.3 will work with some reduced functionality)
    * [Mercurial](https://www.mercurial-scm.org)
    * [Darcs](http://darcs.net)
    * [Subversion](https://subversion.apache.org)
    * [Bazaar](https://bazaar.canonical.com/en)
    * [Fossil](https://www.fossil-scm.org/home/doc/trunk/www/index.wiki)
    * [Pijul](https://pijul.org)
  * Version styles:
    * [PEP 440](https://www.python.org/dev/peps/pep-0440)
    * [Semantic Versioning](https://semver.org)
    * [Haskell Package Versioning Policy](https://pvp.haskell.org)
    * Custom output formats
  * Can be used for projects written in any programming language.
    For Python, this means you do not need a setup.py.



  ```
  pip install dunamai
  ```


  ```console



  $ dunamai from any
  0.2.0.post7.dev0+g29045e8


  $ dunamai from git --no-metadata --style semver
  0.2.0-post.7


  $ dunamai from any --format "v{base}+{distance}.{commit}"
  v0.2.0+7.g29045e8



  $ dunamai from any --bump
  0.2.1.dev7+g29045e8


  $ dunamai from any --format "v{base}" --style pep440
  Version 'v0.2.0' does not conform to the PEP 440 style


  $ dunamai check 0.01.0 --style semver
  Version '0.01.0' does not conform to the Semantic Versioning style


  $ dunamai --help
  $ dunamai from --help
  $ dunamai from git --help
  ```



  ```python
  from dunamai import Version, Style


  version = Version.from_git()
  assert version.serialize() == "0.1.0"



  version = Version.from_any_vcs()
  assert version.serialize() == "0.1.0rc5.post44.dev0+g644252b"
  assert version.serialize(metadata=False) == "0.1.0rc5.post44.dev0"
  assert version.serialize(dirty=True) == "0.1.0rc5.post44.dev0+g644252b.dirty"
  assert version.serialize(style=Style.SemVer) == "0.1.0-rc.5.post.44+g644252b"
  ```

  The `serialize()` method gives you an opinionated, PEP 440-compliant default
  that ensures that versions for untagged commits are compatible with Pip's
  `--pre` flag. The individual parts of the version are also available for you
  to use and inspect as you please:

  ```python
  assert version.base == "0.1.0"
  assert version.stage == "rc"
  assert version.revision == 5
  assert version.distance == 44
  assert version.commit == "g644252b"
  assert version.dirty is True


  assert version.tagged_metadata == "linux"
  ```


  By default, the "v" prefix on the tag is required, unless you specify
  a custom tag pattern. You can either write a regular expression:

  ```console
  $ dunamai from any --pattern "(?P<base>\d+\.\d+\.\d+)"
  ```

  ```python
  from dunamai import Version

  version = Version.from_any_vcs(pattern=r"(?P<base>\d+\.\d+\.\d+)")
  ```

  ...or use a named preset:

  ```console
  $ dunamai from any --pattern default-unprefixed
  ```

  ```python
  from dunamai import Version, Pattern

  version = Version.from_any_vcs(pattern=Pattern.DefaultUnprefixed)
  ```


  Sometimes, you may only have access to an archive of a repository (e.g., a zip file) without the full history.
  Dunamai can still detect a version in some of these cases:

  * For Git, you can configure `git archive` to produce a file with some metadata for Dunamai.

    Add a `.git_archival.json` file to the root of your repository with this content:
    ```
    {
      "hash-full": "$Format:%H$",
      "hash-short": "$Format:%h$",
      "timestamp": "$Format:%cI$",
      "refs": "$Format:%D$",
      "describe": "$Format:$"
    }
    ```

    Add this line to your `.gitattributes` file.
    If you don't already have this file, add it to the root of your repository:
    ```
    .git_archival.json  export-subst
    ```

  * For Mercurial, Dunamai will detect and use an `.hg_archival.txt` file created by `hg archive`.
    It will also recognize `.hgtags` if present.


  Here are the available substitutions for custom formats. If you have a tag like
  `v9!0.1.2-beta.3+other`, then:

  * `{base}` = `0.1.2`
  * `{stage}` = `beta`
  * `{revision}` = `3`
  * `{distance}` is the number of commits since the last
  * `{commit}` is the commit hash (defaults to short form, unless you use `--full-commit`)
  * `{dirty}` expands to either "dirty" or "clean" if you have uncommitted modified files
  * `{tagged_metadata}` = `other`
  * `{epoch}` = `9`
  * `{branch}` = `feature/foo`
  * `{branch_escaped}` = `featurefoo`
  * `{timestamp}` is in the format `YYYYmmddHHMMSS` as UTC

  If you specify a substitution, its value will always be included in the output.
  For conditional formatting, you can do something like this (Bash):

  ```bash
  distance=$(dunamai from any --format "{distance}")
  if [ "$distance" = "0" ]; then
      dunamai from any --format "v{base}"
  else
      dunamai from any --format "v{base}+{distance}.{dirty}"
  fi
  ```


  [Versioneer](https://github.com/warner/python-versioneer) is another great
  library for dynamic versions, but there are some design decisions that
  prompted the creation of Dunamai as an alternative:

  * Versioneer requires a setup.py file to exist, or else `versioneer install`
    will fail, rendering it incompatible with non-setuptools-based projects
    such as those using Poetry or Flit. Dunamai can be used regardless of the
    project's build system.
  * Versioneer has a CLI that generates Python code which needs to be committed
    into your repository, whereas Dunamai is just a normal importable library
    with an optional CLI to help statically include your version string.
  * Versioneer produces the version as an opaque string, whereas Dunamai provides
    a Version class with discrete parts that can then be inspected and serialized
    separately.
  * Versioneer provides customizability through a config file, whereas Dunamai
    aims to offer customizability through its library API and CLI for both
    scripting support and use in other libraries.


  * Setting a `__version__` statically:

    ```console
    $ echo "__version__ = '$(dunamai from any)'" > your_library/_version.py
    ```
    ```python
    
    from your_library._version import __version__
    ```

    Or dynamically (but Dunamai becomes a runtime dependency):

    ```python
    
    import dunamai as _dunamai
    __version__ = _dunamai.get_version("your-library", third_choice=_dunamai.Version.from_any_vcs).serialize()
    ```

  * setup.py (no install-time dependency on Dunamai as long as you use wheels):

    ```python
    from setuptools import setup
    from dunamai import Version

    setup(
        name="your-library",
        version=Version.from_any_vcs().serialize(),
    )
    ```

    Or you could use a static inclusion approach as in the prior example.

  * [Poetry](https://poetry.eustace.io):

    ```console
    $ poetry version $(dunamai from any)
    ```

    Or you can use the [poetry-dynamic-versioning](https://github.com/mtkennerly/poetry-dynamic-versioning) plugin.


  * When using Git, remember that lightweight tags do not store their creation time.
    Therefore, if a commit has multiple lightweight tags,
    we cannot reliably determine which one should be considered the newest.
    The solution is to use annotated tags instead.
  * When using Git, the initial commit must **not** be both tagged and empty
    (i.e., created with `--allow-empty`). This is related to a reporting issue
    in Git. For more info, [click here](https://github.com/mtkennerly/dunamai/issues/14).


pkgId: 62e2c85f31510435d954ddf9b00b67d689e55f139837d89060b0d859daeb6be7
name: python-dwave-neal
arch: src
version: 0.6.0
epoch: 0
release: 1
summary: General Ising graph simulated annealing solver
url: https://github.com/dwavesystems/dwave-neal
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ea03f6f0-32e8-401b-a760-8ead816d9851
location_href: 00013683-python-dwave-neal/python-dwave-neal-0.6.0-1.src.rpm
checksum_type: sha256
description:
  An implementation of a simulated annealing sampler.
  A simulated annealing sampler can be used for approximate Boltzmann sampling or
  heuristic optimization. This implementation approaches the equilibrium
  distribution by performing updates at a sequence of increasing beta values,
  ``beta_schedule``, terminating at the target beta. Each spin is updated once
  in a fixed order per point in the beta_schedule according to a Metropolis-
  Hastings update. When beta is large the target distribution concentrates, at
  equilibrium, over ground states of the model. Samples are guaranteed to match
  the equilibrium for long 'smooth' beta schedules.
  For more information, see Kirkpatrick, S.; Gelatt Jr, C. D.; Vecchi, M. P.
  (1983). "Optimization by Simulated Annealing". Science. 220 (4598): 671–680


pkgId: 281f7902111cf92caf585296dd3415ad4ce04d1fc27e7bbe2f3dd60d46ba7849
name: python-dwave-qbsolv-debuginfo
arch: x86_64
version: 0.3.4
epoch: 0
release: 1
summary: Debug information for package python-dwave-qbsolv
url: https://pypi.org/project/dwave-qbsolv/
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-b6c13a19-29a6-4c6a-b458-62a9bf1e5fa5
rpm_sourcerpm: python-dwave-qbsolv-0.3.4-1.src.rpm
location_href: 00014210-python-dwave-qbsolv/python-dwave-qbsolv-debuginfo-0.3.4-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-dwave-qbsolv.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: d9addd611fd7861cbf3b1e62ee7a68d0f86abaaa44db7f478f5f2a206637b80e
name: python-dwave-qbsolv-debugsource
arch: x86_64
version: 0.3.4
epoch: 0
release: 1
summary: Debug sources for package python-dwave-qbsolv
url: https://pypi.org/project/dwave-qbsolv/
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-b6c13a19-29a6-4c6a-b458-62a9bf1e5fa5
rpm_sourcerpm: python-dwave-qbsolv-0.3.4-1.src.rpm
location_href: 00014210-python-dwave-qbsolv/python-dwave-qbsolv-debugsource-0.3.4-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-dwave-qbsolv.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: ddc143b8a66cba356228f2d65d75427061fc874bcdafdc213e89ad84118f2748
name: python-dynamodb-json
arch: src
version: 1.3
epoch: 0
release: 1
summary: A DynamoDB json util from and to python objects
url: https://github.com/Alonreznik/dynamodb-json
rpm_license: Mozilla
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b0664845-d065-4bb2-a766-99879e4bbf1e
location_href: 00010941-python-dynamodb-json/python-dynamodb-json-1.3-1.src.rpm
checksum_type: sha256
description:
  DynamoDB json util to load and dump strings of Dynamodb json format to python object and vise-versa


  just use pip:
  ```
  pip install dynamodb-json
  ```


  The dynamodb-json util works the same as json loads and dumps functions:
  ```python
  import time
  import uuid
  from datetime import datetime
  from decimal import Decimal

  from dynamodb_json import json_util as json

  json_ = {"MyString": "a",
           "num": 4,
           "MyBool": False,
           "my_dict": {"my_date": datetime.utcnow()},
           "MyNone": None,
           "MyZero": 0,
           "myDecimal": Decimal("19.2"),  # converts Decimal to float, load it as float
           "myLong": long(1938475658493),
           "MyNestedDict": {
               "my_other_nested": {
                   "name": "John",
                   "surname": "Lennon",
                   "MyOtherNone": None,
                   "floaty": float(29.4),
                   "myList": [1, 3, 4, 5, 6, "This Is Sparta!"],
                   "mySet": {1, 3, 4, 5, 6},  # converts set to list, returns as list
                   "myUUID": uuid.uuid4(),  # converts uuid to string, loads it as string
                   "time": time.time()  # converts it to seconds python float, loads it as float
               }
           }
      }

  dynamodb_json = json.dumps(json_)






















  json.loads(dynamodb_json)


















  ```


pkgId: e6f46a62ad61982e83358b0be747637b583c63df0d26cfb06975b39d993bcfd4
name: python-easyargs
arch: src
version: 0.9.4
epoch: 0
release: 1
summary: Making argument parsing easy
url: https://github.com/stedmeister/easyargs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-84919de0-e77b-4550-a57d-49b88d094ce2
location_href: 00003552-python-easyargs/python-easyargs-0.9.4-1.src.rpm
checksum_type: sha256
description:
  A project designed to make command line argument parsing easy.
  There are many ways to create a command line parser in python: argparse, docopt,
  click.  These are all great options, but require quite a lot of configuration
  and sometimes you just need a function to be called.  Enter easyargs.  Define
  the function that you want to be called, decorate it and let easyargs work out
  the command line.  This is probably best shown with an example that takes one
  required argument and two optional ones:
      from __future__ import print_function
      import easyargs
      @easyargs
      def main(name, count=1, greeting='Hello'):
          """A simple greeting program"""
          for i in range(count):
              print('{greeting} {name}!'.format(greeting=greeting, name=name))
      if __name__ == '__main__':
          main()
  In this example, main is inspected, the arg keywords are turned into
  positional arguments and the kwarg keywords will be turned
  into optional arguments.  This can be seen if we run the above script with the
  help flag:
      $ python simple.py -h
      usage: simple_test.py [-h] [--count COUNT] [--greeting GREETING] name
      A simple greeting program
      positional arguments:
        name
      optional arguments:
        -h, --help           show this help message and exit
        --count COUNT
        --greeting GREETING
  A few things worth noting.  Firstly, the description is taken from the docstring
  of the function.  Secondly, there is no need to convert count to an integer.
  Because the default argument is of type int, the value is coerced to an integer:
      $ python simple.py World
      Hello World
      $ python simple.py everybody --count 2 --greeting Hola
      Hola everybody!
      Hola everybody!


pkgId: 84572e0a03c8b3c59ea4895c4d4ee9562b37e396f17688714936b7a917069b0e
name: python-easygui
arch: src
version: 0.98.3
epoch: 0
release: 1
url: https://github.com/robertlugg/easygui
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-81c7d518-474b-4c3f-85ae-47476d13005f
location_href: 00003554-python-easygui/python-easygui-0.98.3-1.src.rpm
checksum_type: sha256
summary:
  EasyGUI is a module for very simple, very easy GUI programming in Python.  EasyGUI is different from other GUI generators in that EasyGUI is NOT event-driven.  Instead, all GUI interactions are invoked by simple function calls.

description:
  Hi everyone.  There hasn't been much activity but thankfully we have a new revision.  Thank you contributors and thank you Stephen Ferg for creating EasyGui.
  You might also consider the following alternatives:
   - https://github.com/aroberge/easygui_qt
   - https://github.com/ponty/psidialogs
  For those who wish to contribute you are welcome to fork this respository.  Or, take a look at the alternatives and contribute there.
  Kind Regards, Robert


pkgId: b62aac8cd43d4b297201a0572504989237874979a4620cbbd1ffdd8d151555ef
name: python-easypost
arch: src
version: 7.11.0
epoch: 0
release: 1
summary: EasyPost Shipping API Client Library for Python
url: https://easypost.com/
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-db8d4e94-4145-4d32-bb38-cee8e18ebf68
location_href: 00013297-python-easypost/python-easypost-7.11.0-1.src.rpm
checksum_type: sha256
description:
  [![CI](https://github.com/EasyPost/easypost-python/workflows/CI/badge.svg)](https://github.com/EasyPost/easypost-python/actions?query=workflow%3ACI)
  [![Coverage Status](https://coveralls.io/repos/github/EasyPost/easypost-python/badge.svg)](https://coveralls.io/github/EasyPost/easypost-python)
  [![PyPI version](https://badge.fury.io/py/easypost.svg)](https://badge.fury.io/py/easypost)

  EasyPost, the simple shipping solution. You can sign up for an account at <https://easypost.com>.



  The library is tested against Python3 and should be compatible with PyPy3.

  ```bash
  pip install easypost
  ```

  ```python

  import easypost
  ```



  A simple create & buy shipment example:

  ```python
  import os
  import easypost

  easypost.api_key = os.getenv('EASYPOST_API_KEY')

  shipment = easypost.Shipment.create(
      from_address = {
          "name": "EasyPost",
          "street1": "118 2nd Street",
          "street2": "4th Floor",
          "city": "San Francisco",
          "state": "CA",
          "zip": "94105",
          "country": "US",
          "phone": "415-456-7890",
      },
      to_address = {
          "name": "Dr. Steve Brule",
          "street1": "179 N Harbor Dr",
          "city": "Redondo Beach",
          "state": "CA",
          "zip": "90277",
          "country": "US",
          "phone": "310-808-5243",
      },
      parcel = {
          "length": 10.2,
          "width": 7.8,
          "height": 4.3,
          "weight": 21.2,
      },
  )

  shipment.buy(rate=shipment.lowest_rate())

  print(shipment)
  ```



  API documentation can be found at: <https://easypost.com/docs/api>.

  Library documentation can be found on the web at: <https://easypost.github.io/easypost-python/> or locally in the `docs` directory.

  Upgrading major versions of this project? Refer to the [Upgrade Guide](UPGRADE_GUIDE.md).



  New features and bug fixes are released on the latest major release of this library. If you are on an older major release of this library, we recommend upgrading to the most recent release to take advantage of new features, bug fixes, and security patches. Older versions of this library will continue to work and be available as long as the API version they are tied to remains active; however, they will not receive updates and are considered EOL.

  For additional support, see our [org-wide support policy](https://github.com/EasyPost/.github/blob/main/SUPPORT.md).



  ```bash

  make install


  make lint


  make format


  EASYPOST_TEST_API_KEY=123... EASYPOST_PROD_API_KEY=123... make test


  EASYPOST_TEST_API_KEY=123... EASYPOST_PROD_API_KEY=123... make coverage


  make scan


  make docs


  git submodule init
  git submodule update --remote
  ```



  The test suite in this project was specifically built to produce consistent results on every run, regardless of when they run or who is running them. This project uses [VCR](https://github.com/kevin1024/vcrpy) to record and replay HTTP requests and responses via "cassettes". When the suite is run, the HTTP requests and responses for each test function will be saved to a cassette if they do not exist already and replayed from this saved file if they do, which saves the need to make live API calls on every test run. If you receive errors about a cassette expiring, delete and re-record the cassette to ensure the data is up-to-date.

  **Sensitive Data:** We've made every attempt to include scrubbers for sensitive data when recording cassettes so that PII or sensitive info does not persist in version control; however, please ensure when recording or re-recording cassettes that prior to committing your changes, no PII or sensitive information gets persisted by inspecting the cassette.

  **Making Changes:** If you make an addition to this project, the request/response will get recorded automatically for you if the `@pytest.mark.vcr()` decorator is included on the test function. When making changes to this project, you'll need to re-record the associated cassette to force a new live API call for that test which will then record the request/response used on the next run.

  **Test Data:** The test suite has been populated with various helpful fixtures that are available for use, each completely independent from a particular user **with the exception of the USPS carrier account ID** (see [Unit Test API Keys](#unit-test-api-keys) for more information) which has a fallback value of our internal testing user's ID. Some fixtures use hard-coded dates that may need to be incremented if cassettes get re-recorded (such as reports or pickups).



  The following are required on every test run:

  - `EASYPOST_TEST_API_KEY`
  - `EASYPOST_PROD_API_KEY`

  Some tests may require an EasyPost user with a particular set of enabled features such as a `Partner` user when creating referrals. We have attempted to call out these functions in their respective docstrings. The following are required when you need to re-record cassettes for applicable tests:

  - `USPS_CARRIER_ACCOUNT_ID` (eg: one-call buying a shipment for non-EasyPost employees)
  - `PARTNER_USER_PROD_API_KEY` (eg: creating a referral user)
  - `REFERRAL_CUSTOMER_PROD_API_KEY` (eg: adding a credit card to a referral user)


pkgId: 9bd99fa4bdfe436a1e44d800d0ce52443b61ed55f6dea814f4941a402ceb6128
name: python-ecdsa
arch: src
version: 0.18.0
epoch: 0
release: 1
summary: ECDSA cryptographic signature library (pure python)
url: http://github.com/tlsfuzzer/python-ecdsa
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b1654cad-754a-469e-8bcd-38a76b3e3ff5
location_href: 00009176-python-ecdsa/python-ecdsa-0.18.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://github.com/tlsfuzzer/python-ecdsa/workflows/GitHub%20CI/badge.svg?branch=master)](https://github.com/tlsfuzzer/python-ecdsa/actions?query=workflow%3A%22GitHub+CI%22+branch%3Amaster)
  [![Documentation Status](https://readthedocs.org/projects/ecdsa/badge/?version=latest)](https://ecdsa.readthedocs.io/en/latest/?badge=latest)
  [![Coverage Status](https://coveralls.io/repos/github/tlsfuzzer/python-ecdsa/badge.svg?branch=master)](https://coveralls.io/github/tlsfuzzer/python-ecdsa?branch=master)
  ![condition coverage](https://img.shields.io/endpoint?url=https://gist.githubusercontent.com/tomato42/9b6ca1f3410207fbeca785a178781651/raw/python-ecdsa-condition-coverage.json)
  [![Language grade: Python](https://img.shields.io/lgtm/grade/python/g/tlsfuzzer/python-ecdsa.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/tlsfuzzer/python-ecdsa/context:python)
  [![Total alerts](https://img.shields.io/lgtm/alerts/g/tlsfuzzer/python-ecdsa.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/tlsfuzzer/python-ecdsa/alerts/)
  [![Latest Version](https://img.shields.io/pypi/v/ecdsa.svg?style=flat)](https://pypi.python.org/pypi/ecdsa/)
  ![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg?style=flat)


  This is an easy-to-use implementation of ECC (Elliptic Curve Cryptography)
  with support for ECDSA (Elliptic Curve Digital Signature Algorithm),
  EdDSA (Edwards-curve Digital Signature Algorithm) and ECDH
  (Elliptic Curve Diffie-Hellman), implemented purely in Python, released under
  the MIT license. With this library, you can quickly create key pairs (signing
  key and verifying key), sign messages, and verify the signatures. You can
  also agree on a shared secret key based on exchanged public keys.
  The keys and signatures are very short, making them easy to handle and
  incorporate into other protocols.

  **NOTE: This library should not be used in production settings, see [Security](#Security) for more details.**



  This library provides key generation, signing, verifying, and shared secret
  derivation for five
  popular NIST "Suite B" GF(p) (_prime field_) curves, with key lengths of 192,
  224, 256, 384, and 521 bits. The "short names" for these curves, as known by
  the OpenSSL tool (`openssl ecparam -list_curves`), are: `prime192v1`,
  `secp224r1`, `prime256v1`, `secp384r1`, and `secp521r1`. It includes the
  256-bit curve `secp256k1` used by Bitcoin. There is also support for the
  regular (non-twisted) variants of Brainpool curves from 160 to 512 bits. The
  "short names" of those curves are: `brainpoolP160r1`, `brainpoolP192r1`,
  `brainpoolP224r1`, `brainpoolP256r1`, `brainpoolP320r1`, `brainpoolP384r1`,
  `brainpoolP512r1`. Few of the small curves from SEC standard are also
  included (mainly to speed-up testing of the library), those are:
  `secp112r1`, `secp112r2`, `secp128r1`, and `secp160r1`.
  Key generation, siging and verifying is also supported for Ed25519 and
  Ed448 curves.
  No other curves are included, but it is not too hard to add support for more
  curves over prime fields.



  This library uses only Python and the 'six' package. It is compatible with
  Python 2.6, 2.7, and 3.3+. It also supports execution on alternative
  implementations like pypy and pypy3.

  If `gmpy2` or `gmpy` is installed, they will be used for faster arithmetic.
  Either of them can be installed after this library is installed,
  `python-ecdsa` will detect their presence on start-up and use them
  automatically.
  You should prefer `gmpy2` on Python3 for optimal performance.

  To run the OpenSSL compatibility tests, the 'openssl' tool must be in your
  `PATH`. This release has been tested successfully against OpenSSL 0.9.8o,
  1.0.0a, 1.0.2f, 1.1.1d and 3.0.1 (among others).




  This library is available on PyPI, it's recommended to install it using `pip`:

  ```
  pip install ecdsa
  ```

  In case higher performance is wanted and using native code is not a problem,
  it's possible to specify installation together with `gmpy2`:

  ```
  pip install ecdsa[gmpy2]
  ```

  or (slower, legacy option):
  ```
  pip install ecdsa[gmpy]
  ```



  The following table shows how long this library takes to generate key pairs
  (`keygen`), to sign data (`sign`), to verify those signatures (`verify`),
  to derive a shared secret (`ecdh`), and
  to verify the signatures with no key-specific precomputation (`no PC verify`).
  All those values are in seconds.
  For convenience, the inverses of those values are also provided:
  how many keys per second can be generated (`keygen/s`), how many signatures
  can be made per second (`sign/s`), how many signatures can be verified
  per second (`verify/s`), how many shared secrets can be derived per second
  (`ecdh/s`), and how many signatures with no key specific
  precomputation can be verified per second (`no PC verify/s`). The size of raw
  signature (generally the smallest
  the way a signature can be encoded) is also provided in the `siglen` column.
  Use `tox -e speed` to generate this table on your own computer.
  On an Intel Core i7 4790K @ 4.0GHz I'm getting the following performance:

  ```
                    siglen    keygen   keygen/s      sign     sign/s    verify   verify/s  no PC verify  no PC verify/s
          NIST192p:     48   0.00032s   3134.06   0.00033s   2985.53   0.00063s   1598.36       0.00129s         774.43
          NIST224p:     56   0.00040s   2469.24   0.00042s   2367.88   0.00081s   1233.41       0.00170s         586.66
          NIST256p:     64   0.00051s   1952.73   0.00054s   1867.80   0.00098s   1021.86       0.00212s         471.27
          NIST384p:     96   0.00107s    935.92   0.00111s    904.23   0.00203s    491.77       0.00446s         224.00
          NIST521p:    132   0.00210s    475.52   0.00215s    464.16   0.00398s    251.28       0.00874s         114.39
         SECP256k1:     64   0.00052s   1921.54   0.00054s   1847.49   0.00105s    948.68       0.00210s         477.01
   BRAINPOOLP160r1:     40   0.00025s   4003.88   0.00026s   3845.12   0.00053s   1893.93       0.00105s         949.92
   BRAINPOOLP192r1:     48   0.00033s   3043.97   0.00034s   2975.98   0.00063s   1581.50       0.00135s         742.29
   BRAINPOOLP224r1:     56   0.00041s   2436.44   0.00043s   2315.51   0.00078s   1278.49       0.00180s         556.16
   BRAINPOOLP256r1:     64   0.00053s   1892.49   0.00054s   1846.24   0.00114s    875.64       0.00229s         437.25
   BRAINPOOLP320r1:     80   0.00073s   1361.26   0.00076s   1309.25   0.00143s    699.29       0.00322s         310.49
   BRAINPOOLP384r1:     96   0.00107s    931.29   0.00111s    901.80   0.00230s    434.19       0.00476s         210.20
   BRAINPOOLP512r1:    128   0.00207s    483.41   0.00212s    471.42   0.00425s    235.43       0.00912s         109.61
         SECP112r1:     28   0.00015s   6672.53   0.00016s   6440.34   0.00031s   3265.41       0.00056s        1774.20
         SECP112r2:     28   0.00015s   6697.11   0.00015s   6479.98   0.00028s   3524.72       0.00058s        1716.16
         SECP128r1:     32   0.00018s   5497.65   0.00019s   5272.89   0.00036s   2747.39       0.00072s        1396.16
         SECP160r1:     42   0.00025s   3949.32   0.00026s   3894.45   0.00046s   2153.85       0.00102s         985.07
           Ed25519:     64   0.00076s   1324.48   0.00042s   2405.01   0.00109s    918.05       0.00344s         290.50
             Ed448:    114   0.00176s    569.53   0.00115s    870.94   0.00282s    355.04       0.01024s          97.69

                         ecdh     ecdh/s
          NIST192p:   0.00104s    964.89
          NIST224p:   0.00134s    748.63
          NIST256p:   0.00170s    587.08
          NIST384p:   0.00352s    283.90
          NIST521p:   0.00717s    139.51
         SECP256k1:   0.00154s    648.40
   BRAINPOOLP160r1:   0.00082s   1220.70
   BRAINPOOLP192r1:   0.00105s    956.75
   BRAINPOOLP224r1:   0.00136s    734.52
   BRAINPOOLP256r1:   0.00178s    563.32
   BRAINPOOLP320r1:   0.00252s    397.23
   BRAINPOOLP384r1:   0.00376s    266.27
   BRAINPOOLP512r1:   0.00733s    136.35
         SECP112r1:   0.00046s   2180.40
         SECP112r2:   0.00045s   2229.14
         SECP128r1:   0.00054s   1868.15
         SECP160r1:   0.00080s   1243.98
  ```

  To test performance with `gmpy2` loaded, use `tox -e speedgmpy2`.
  On the same machine I'm getting the following performance with `gmpy2`:
  ```
                    siglen    keygen   keygen/s      sign     sign/s    verify   verify/s  no PC verify  no PC verify/s
          NIST192p:     48   0.00017s   5933.40   0.00017s   5751.70   0.00032s   3125.28       0.00067s        1502.41
          NIST224p:     56   0.00021s   4782.87   0.00022s   4610.05   0.00040s   2487.04       0.00089s        1126.90
          NIST256p:     64   0.00023s   4263.98   0.00024s   4125.16   0.00045s   2200.88       0.00098s        1016.82
          NIST384p:     96   0.00041s   2449.54   0.00042s   2399.96   0.00083s   1210.57       0.00172s         581.43
          NIST521p:    132   0.00071s   1416.07   0.00072s   1389.81   0.00144s    692.93       0.00312s         320.40
         SECP256k1:     64   0.00024s   4245.05   0.00024s   4122.09   0.00045s   2206.40       0.00094s        1068.32
   BRAINPOOLP160r1:     40   0.00014s   6939.17   0.00015s   6681.55   0.00029s   3452.43       0.00057s        1769.81
   BRAINPOOLP192r1:     48   0.00017s   5920.05   0.00017s   5774.36   0.00034s   2979.00       0.00069s        1453.19
   BRAINPOOLP224r1:     56   0.00021s   4732.12   0.00022s   4622.65   0.00041s   2422.47       0.00087s        1149.87
   BRAINPOOLP256r1:     64   0.00024s   4233.02   0.00024s   4115.20   0.00047s   2143.27       0.00098s        1015.60
   BRAINPOOLP320r1:     80   0.00032s   3162.38   0.00032s   3077.62   0.00063s   1598.83       0.00136s         737.34
   BRAINPOOLP384r1:     96   0.00041s   2436.88   0.00042s   2395.62   0.00083s   1202.68       0.00178s         562.85
   BRAINPOOLP512r1:    128   0.00063s   1587.60   0.00064s   1558.83   0.00125s    799.96       0.00281s         355.83
         SECP112r1:     28   0.00009s  11118.66   0.00009s  10775.48   0.00018s   5456.00       0.00033s        3020.83
         SECP112r2:     28   0.00009s  11322.97   0.00009s  10857.71   0.00017s   5748.77       0.00032s        3094.28
         SECP128r1:     32   0.00010s  10078.39   0.00010s   9665.27   0.00019s   5200.58       0.00036s        2760.88
         SECP160r1:     42   0.00015s   6875.51   0.00015s   6647.35   0.00029s   3422.41       0.00057s        1768.35
           Ed25519:     64   0.00030s   3322.56   0.00018s   5568.63   0.00046s   2165.35       0.00153s         654.02
             Ed448:    114   0.00060s   1680.53   0.00039s   2567.40   0.00096s   1036.67       0.00350s         285.62

                         ecdh     ecdh/s
          NIST192p:   0.00050s   1985.70
          NIST224p:   0.00066s   1524.16
          NIST256p:   0.00071s   1413.07
          NIST384p:   0.00127s    788.89
          NIST521p:   0.00230s    434.85
         SECP256k1:   0.00071s   1409.95
   BRAINPOOLP160r1:   0.00042s   2374.65
   BRAINPOOLP192r1:   0.00051s   1960.01
   BRAINPOOLP224r1:   0.00066s   1518.37
   BRAINPOOLP256r1:   0.00071s   1399.90
   BRAINPOOLP320r1:   0.00100s    997.21
   BRAINPOOLP384r1:   0.00129s    777.51
   BRAINPOOLP512r1:   0.00210s    475.99
         SECP112r1:   0.00022s   4457.70
         SECP112r2:   0.00024s   4252.33
         SECP128r1:   0.00028s   3589.31
         SECP160r1:   0.00043s   2305.02
  ```

  (there's also `gmpy` version, execute it using `tox -e speedgmpy`)

  For comparison, a highly optimised implementation (including curve-specific
  assembly for some curves), like the one in OpenSSL 1.1.1d, provides the
  following performance numbers on the same machine.
  Run `openssl speed ecdsa` and `openssl speed ecdh` to reproduce it:
  ```
                                sign    verify    sign/s verify/s
   192 bits ecdsa (nistp192)   0.0002s   0.0002s   4785.6   5380.7
   224 bits ecdsa (nistp224)   0.0000s   0.0001s  22475.6   9822.0
   256 bits ecdsa (nistp256)   0.0000s   0.0001s  45069.6  14166.6
   384 bits ecdsa (nistp384)   0.0008s   0.0006s   1265.6   1648.1
   521 bits ecdsa (nistp521)   0.0003s   0.0005s   3753.1   1819.5
   256 bits ecdsa (brainpoolP256r1)   0.0003s   0.0003s   2983.5   3333.2
   384 bits ecdsa (brainpoolP384r1)   0.0008s   0.0007s   1258.8   1528.1
   512 bits ecdsa (brainpoolP512r1)   0.0015s   0.0012s    675.1    860.1

                                sign    verify    sign/s verify/s
   253 bits EdDSA (Ed25519)   0.0000s   0.0001s  28217.9  10897.7
   456 bits EdDSA (Ed448)     0.0003s   0.0005s   3926.5   2147.7

                                 op      op/s
   192 bits ecdh (nistp192)   0.0002s   4853.4
   224 bits ecdh (nistp224)   0.0001s  15252.1
   256 bits ecdh (nistp256)   0.0001s  18436.3
   384 bits ecdh (nistp384)   0.0008s   1292.7
   521 bits ecdh (nistp521)   0.0003s   2884.7
   256 bits ecdh (brainpoolP256r1)   0.0003s   3066.5
   384 bits ecdh (brainpoolP384r1)   0.0008s   1298.0
   512 bits ecdh (brainpoolP512r1)   0.0014s    694.8
  ```

  Keys and signature can be serialized in different ways (see Usage, below).
  For a NIST192p key, the three basic representations require strings of the
  following lengths (in bytes):

      to_string:  signkey= 24, verifykey= 48, signature=48
      compressed: signkey=n/a, verifykey= 25, signature=n/a
      DER:        signkey=106, verifykey= 80, signature=55
      PEM:        signkey=278, verifykey=162, (no support for PEM signatures)



  In 2006, Peter Pearson announced his pure-python implementation of ECDSA in a
  [message to sci.crypt][1], available from his [download site][2]. In 2010,
  Brian Warner wrote a wrapper around this code, to make it a bit easier and
  safer to use. In 2020, Hubert Kario included an implementation of elliptic
  curve cryptography that uses Jacobian coordinates internally, improving
  performance about 20-fold. You are looking at the README for this wrapper.

  [1]: http://www.derkeiler.com/Newsgroups/sci.crypt/2006-01/msg00651.html
  [2]: http://webpages.charter.net/curryfans/peter/downloads.html



  To run the full test suite, do this:

      tox -e coverage

  On an Intel Core i7 4790K @ 4.0GHz, the tests take about 18 seconds to execute.
  The test suite uses
  [`hypothesis`](https://github.com/HypothesisWorks/hypothesis) so there is some
  inherent variability in the test suite execution time.

  One part of `test_pyecdsa.py` and `test_ecdh.py` checks compatibility with
  OpenSSL, by running the "openssl" CLI tool, make sure it's in your `PATH` if
  you want to test compatibility with it (if OpenSSL is missing, too old, or
  doesn't support all the curves supported in upstream releases you will see
  skipped tests in the above `coverage` run).



  This library was not designed with security in mind. If you are processing
  data that needs to be protected we suggest you use a quality wrapper around
  OpenSSL. [pyca/cryptography](https://cryptography.io) is one example of such
  a wrapper. The primary use-case of this library is as a portable library for
  interoperability testing and as a teaching tool.

  **This library does not protect against side-channel attacks.**

  Do not allow attackers to measure how long it takes you to generate a key pair
  or sign a message. Do not allow attackers to run code on the same physical
  machine when key pair generation or signing is taking place (this includes
  virtual machines). Do not allow attackers to measure how much power your
  computer uses while generating the key pair or signing a message. Do not allow
  attackers to measure RF interference coming from your computer while generating
  a key pair or signing a message. Note: just loading the private key will cause
  key pair generation. Other operations or attack vectors may also be
  vulnerable to attacks. **For a sophisticated attacker observing just one
  operation with a private key will be sufficient to completely
  reconstruct the private key**.

  Please also note that any Pure-python cryptographic library will be vulnerable
  to the same side-channel attacks. This is because Python does not provide
  side-channel secure primitives (with the exception of
  [`hmac.compare_digest()`][3]), making side-channel secure programming
  impossible.

  This library depends upon a strong source of random numbers. Do not use it on
  a system where `os.urandom()` does not provide cryptographically secure
  random numbers.

  [3]: https://docs.python.org/3/library/hmac.html#hmac.compare_digest



  You start by creating a `SigningKey`. You can use this to sign data, by passing
  in data as a byte string and getting back the signature (also a byte string).
  You can also ask a `SigningKey` to give you the corresponding `VerifyingKey`.
  The `VerifyingKey` can be used to verify a signature, by passing it both the
  data string and the signature byte string: it either returns True or raises
  `BadSignatureError`.

  ```python
  from ecdsa import SigningKey
  sk = SigningKey.generate() # uses NIST192p
  vk = sk.verifying_key
  signature = sk.sign(b"message")
  assert vk.verify(signature, b"message")
  ```

  Each `SigningKey`/`VerifyingKey` is associated with a specific curve, like
  NIST192p (the default one). Longer curves are more secure, but take longer to
  use, and result in longer keys and signatures.

  ```python
  from ecdsa import SigningKey, NIST384p
  sk = SigningKey.generate(curve=NIST384p)
  vk = sk.verifying_key
  signature = sk.sign(b"message")
  assert vk.verify(signature, b"message")
  ```

  The `SigningKey` can be serialized into several different formats: the shortest
  is to call `s=sk.to_string()`, and then re-create it with
  `SigningKey.from_string(s, curve)` . This short form does not record the
  curve, so you must be sure to pass to `from_string()` the same curve you used
  for the original key. The short form of a NIST192p-based signing key is just 24
  bytes long. If a point encoding is invalid or it does not lie on the specified
  curve, `from_string()` will raise `MalformedPointError`.

  ```python
  from ecdsa import SigningKey, NIST384p
  sk = SigningKey.generate(curve=NIST384p)
  sk_string = sk.to_string()
  sk2 = SigningKey.from_string(sk_string, curve=NIST384p)
  print(sk_string.hex())
  print(sk2.to_string().hex())
  ```

  Note: while the methods are called `to_string()` the type they return is
  actually `bytes`, the "string" part is leftover from Python 2.

  `sk.to_pem()` and `sk.to_der()` will serialize the signing key into the same
  formats that OpenSSL uses. The PEM file looks like the familiar ASCII-armored
  `"-----BEGIN EC PRIVATE KEY-----"` base64-encoded format, and the DER format
  is a shorter binary form of the same data.
  `SigningKey.from_pem()/.from_der()` will undo this serialization. These
  formats include the curve name, so you do not need to pass in a curve
  identifier to the deserializer. In case the file is malformed `from_der()`
  and `from_pem()` will raise `UnexpectedDER` or` MalformedPointError`.

  ```python
  from ecdsa import SigningKey, NIST384p
  sk = SigningKey.generate(curve=NIST384p)
  sk_pem = sk.to_pem()
  sk2 = SigningKey.from_pem(sk_pem)

  ```

  Likewise, the `VerifyingKey` can be serialized in the same way:
  `vk.to_string()/VerifyingKey.from_string()`, `to_pem()/from_pem()`, and
  `to_der()/from_der()`. The same `curve=` argument is needed for
  `VerifyingKey.from_string()`.

  ```python
  from ecdsa import SigningKey, VerifyingKey, NIST384p
  sk = SigningKey.generate(curve=NIST384p)
  vk = sk.verifying_key
  vk_string = vk.to_string()
  vk2 = VerifyingKey.from_string(vk_string, curve=NIST384p)


  from ecdsa import SigningKey, VerifyingKey, NIST384p
  sk = SigningKey.generate(curve=NIST384p)
  vk = sk.verifying_key
  vk_pem = vk.to_pem()
  vk2 = VerifyingKey.from_pem(vk_pem)

  ```

  There are a couple of different ways to compute a signature. Fundamentally,
  ECDSA takes a number that represents the data being signed, and returns a
  pair of numbers that represent the signature. The `hashfunc=` argument to
  `sk.sign()` and `vk.verify()` is used to turn an arbitrary string into a
  fixed-length digest, which is then turned into a number that ECDSA can sign,
  and both sign and verify must use the same approach. The default value is
  `hashlib.sha1`, but if you use NIST256p or a longer curve, you can use
  `hashlib.sha256` instead.

  There are also multiple ways to represent a signature. The default
  `sk.sign()` and `vk.verify()` methods present it as a short string, for
  simplicity and minimal overhead. To use a different scheme, use the
  `sk.sign(sigencode=)` and `vk.verify(sigdecode=)` arguments. There are helper
  functions in the `ecdsa.util` module that can be useful here.

  It is also possible to create a `SigningKey` from a "seed", which is
  deterministic. This can be used in protocols where you want to derive
  consistent signing keys from some other secret, for example when you want
  three separate keys and only want to store a single master secret. You should
  start with a uniformly-distributed unguessable seed with about `curve.baselen`
  bytes of entropy, and then use one of the helper functions in `ecdsa.util` to
  convert it into an integer in the correct range, and then finally pass it
  into `SigningKey.from_secret_exponent()`, like this:

  ```python
  import os
  from ecdsa import NIST384p, SigningKey
  from ecdsa.util import randrange_from_seed__trytryagain

  def make_key(seed):
    secexp = randrange_from_seed__trytryagain(seed, NIST384p.order)
    return SigningKey.from_secret_exponent(secexp, curve=NIST384p)

  seed = os.urandom(NIST384p.baselen) # or other starting point
  sk1a = make_key(seed)
  sk1b = make_key(seed)

  assert sk1a.to_string() == sk1b.to_string()
  sk2 = make_key(b"2-"+seed)  # different key
  assert sk1a.to_string() != sk2.to_string()
  ```

  In case the application will verify a lot of signatures made with a single
  key, it's possible to precompute some of the internal values to make
  signature verification significantly faster. The break-even point occurs at
  about 100 signatures verified.

  To perform precomputation, you can call the `precompute()` method
  on `VerifyingKey` instance:
  ```python
  from ecdsa import SigningKey, NIST384p
  sk = SigningKey.generate(curve=NIST384p)
  vk = sk.verifying_key
  vk.precompute()
  signature = sk.sign(b"message")
  assert vk.verify(signature, b"message")
  ```

  Once `precompute()` was called, all signature verifications with this key will
  be faster to execute.



  To produce signatures that can be verified by OpenSSL tools, or to verify
  signatures that were produced by those tools, use:

  ```python







  import hashlib
  from ecdsa import SigningKey, VerifyingKey
  from ecdsa.util import sigencode_der, sigdecode_der

  with open("vk.pem") as f:
     vk = VerifyingKey.from_pem(f.read())

  with open("data", "rb") as f:
     data = f.read()

  with open("data.sig", "rb") as f:
     signature = f.read()

  assert vk.verify(signature, data, hashlib.sha256, sigdecode=sigdecode_der)

  with open("sk.pem") as f:
     sk = SigningKey.from_pem(f.read(), hashlib.sha256)

  new_signature = sk.sign_deterministic(data, sigencode=sigencode_der)

  with open("data.sig2", "wb") as f:
     f.write(new_signature)


  ```

  Note: if compatibility with OpenSSL 1.0.0 or earlier is necessary, the
  `sigencode_string` and `sigdecode_string` from `ecdsa.util` can be used for
  respectively writing and reading the signatures.

  The keys also can be written in format that openssl can handle:

  ```python
  from ecdsa import SigningKey, VerifyingKey

  with open("sk.pem") as f:
      sk = SigningKey.from_pem(f.read())
  with open("sk.pem", "wb") as f:
      f.write(sk.to_pem())

  with open("vk.pem") as f:
      vk = VerifyingKey.from_pem(f.read())
  with open("vk.pem", "wb") as f:
      f.write(vk.to_pem())
  ```



  Creating a signing key with `SigningKey.generate()` requires some form of
  entropy (as opposed to
  `from_secret_exponent`/`from_string`/`from_der`/`from_pem`,
  which are deterministic and do not require an entropy source). The default
  source is `os.urandom()`, but you can pass any other function that behaves
  like `os.urandom` as the `entropy=` argument to do something different. This
  may be useful in unit tests, where you want to achieve repeatable results. The
  `ecdsa.util.PRNG` utility is handy here: it takes a seed and produces a strong
  pseudo-random stream from it:

  ```python
  from ecdsa.util import PRNG
  from ecdsa import SigningKey
  rng1 = PRNG(b"seed")
  sk1 = SigningKey.generate(entropy=rng1)
  rng2 = PRNG(b"seed")
  sk2 = SigningKey.generate(entropy=rng2)

  ```

  Likewise, ECDSA signature generation requires a random number, and each
  signature must use a different one (using the same number twice will
  immediately reveal the private signing key). The `sk.sign()` method takes an
  `entropy=` argument which behaves the same as `SigningKey.generate(entropy=)`.



  If you call `SigningKey.sign_deterministic(data)` instead of `.sign(data)`,
  the code will generate a deterministic signature instead of a random one.
  This uses the algorithm from RFC6979 to safely generate a unique `k` value,
  derived from the private key and the message being signed. Each time you sign
  the same message with the same key, you will get the same signature (using
  the same `k`).

  This may become the default in a future version, as it is not vulnerable to
  failures of the entropy source.



  Create a NIST192p key pair and immediately save both to disk:

  ```python
  from ecdsa import SigningKey
  sk = SigningKey.generate()
  vk = sk.verifying_key
  with open("private.pem", "wb") as f:
      f.write(sk.to_pem())
  with open("public.pem", "wb") as f:
      f.write(vk.to_pem())
  ```

  Load a signing key from disk, use it to sign a message (using SHA-1), and write
  the signature to disk:

  ```python
  from ecdsa import SigningKey
  with open("private.pem") as f:
      sk = SigningKey.from_pem(f.read())
  with open("message", "rb") as f:
      message = f.read()
  sig = sk.sign(message)
  with open("signature", "wb") as f:
      f.write(sig)
  ```

  Load the verifying key, message, and signature from disk, and verify the
  signature (assume SHA-1 hash):

  ```python
  from ecdsa import VerifyingKey, BadSignatureError
  vk = VerifyingKey.from_pem(open("public.pem").read())
  with open("message", "rb") as f:
      message = f.read()
  with open("signature", "rb") as f:
      sig = f.read()
  try:
      vk.verify(sig, message)
      print "good signature"
  except BadSignatureError:
      print "BAD SIGNATURE"
  ```

  Create a NIST521p key pair:

  ```python
  from ecdsa import SigningKey, NIST521p
  sk = SigningKey.generate(curve=NIST521p)
  vk = sk.verifying_key
  ```

  Create three independent signing keys from a master seed:

  ```python
  from ecdsa import NIST192p, SigningKey
  from ecdsa.util import randrange_from_seed__trytryagain

  def make_key_from_seed(seed, curve=NIST192p):
      secexp = randrange_from_seed__trytryagain(seed, curve.order)
      return SigningKey.from_secret_exponent(secexp, curve)

  sk1 = make_key_from_seed("1:%s" % seed)
  sk2 = make_key_from_seed("2:%s" % seed)
  sk3 = make_key_from_seed("3:%s" % seed)
  ```

  Load a verifying key from disk and print it using hex encoding in
  uncompressed and compressed format (defined in X9.62 and SEC1 standards):

  ```python
  from ecdsa import VerifyingKey

  with open("public.pem") as f:
      vk = VerifyingKey.from_pem(f.read())

  print("uncompressed: {0}".format(vk.to_string("uncompressed").hex()))
  print("compressed: {0}".format(vk.to_string("compressed").hex()))
  ```

  Load a verifying key from a hex string from compressed format, output
  uncompressed:

  ```python
  from ecdsa import VerifyingKey, NIST256p

  comp_str = '022799c0d0ee09772fdd337d4f28dc155581951d07082fb19a38aa396b67e77759'
  vk = VerifyingKey.from_string(bytearray.fromhex(comp_str), curve=NIST256p)
  print(vk.to_string("uncompressed").hex())
  ```

  ECDH key exchange with remote party:

  ```python
  from ecdsa import ECDH, NIST256p

  ecdh = ECDH(curve=NIST256p)
  ecdh.generate_private_key()
  local_public_key = ecdh.get_public_key()

  with open("remote_public_key.pem") as e:
      remote_public_key = e.read()
  ecdh.load_received_public_key_pem(remote_public_key)
  secret = ecdh.generate_sharedsecret_bytes()
  ```


pkgId: eb37bbb7771f950fefd6919d466076bfed28e2f9cad63e94a204d3ab6010515a
name: python-ecos
arch: src
version: 2.0.12
epoch: 0
release: 1
summary: This is the Python package for ECOS: Embedded Cone Solver. See Github page for more information.
url: http://github.com/embotech/ecos
rpm_license: GPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-72ec0de5-9177-4023-b36a-537fcb3792fa
location_href: 00009951-python-ecos/python-ecos-2.0.12-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](http://github.com/embotech/ecos-python/workflows/build/badge.svg?event=push)](https://github.com/embotech/ecos-python/actions/workflows/build.yml)


  **Visit www.embotech.com/ECOS for detailed information on ECOS.**

  ECOS is a numerical software for solving convex second-order cone
  programs (SOCPs) of type
  ```
  min  c'*x
  s.t. A*x = b
       G*x <=_K h
  ```
  where the last inequality is generalized, i.e. `h - G*x` belongs to the
  cone `K`. ECOS supports the positive orthant `R_+` and second-order
  cones `Q_n` defined as
  ```
  Q_n = { (t,x) | t >= || x ||_2 }
  ```
  In the definition above, t is a scalar and `x` is in `R_{n-1}`. The cone
  `K` is therefore a direct product of the positive orthant and
  second-order cones:
  ```
  K = R_+ x Q_n1 x ... x Q_nN
  ```


  The latest version of ECOS is available via `pip`:

      pip install ecos

  This will download the relevant wheel for your machine.


  If you are attempting to build the Python extension from source, then
  use

      make install

  This will use the latest tag on git to version your local installation
  of ECOS.

  You will need [Numpy](http://www.numpy.org/)
  and [Scipy](http://www.scipy.org/). For installation instructions, see
  their respective pages.

  You may need `sudo` privileges for a global installation.


  Windows users may experience some extreme pain when installing ECOS from
  source for Python 2.7. We suggest switching to Linux or Mac OSX.

  If you must use (or insist on using) Windows, we suggest using
  the [Miniconda](http://repo.continuum.io/miniconda/)
  distribution to minimize this pain.

  If during the installation process, you see the error message
  `Unable to find vcvarsall.bat`, you will need to install
  [Microsoft Visual Studio Express 2008](go.microsoft.com/?linkid=7729279),
  since *Python 2.7* is built against the 2008 compiler.

  If using a newer version of Python, you can use a newer version of
  Visual Studio. For instance, Python 3.3 is built against [Visual Studio
  2010](http://go.microsoft.com/?linkid=9709949).



  After installing the ECOS interface, you must import the module with
  ```
  import ecos
  ```
  This module provides a single function `ecos` with one of the following calling sequences:
  ```
  solution = ecos.solve(c,G,h,dims)
  solution = ecos.solve(c,G,h,dims,A,b,**kwargs)
  ```
  The arguments `c`, `h`, and `b` are Numpy arrays (i.e., matrices with a single
  column).  The arguments `G` and `A` are Scipy *sparse* matrices in CSR format;
  if they are not of the proper format, ECOS will attempt to convert them.  The
  argument `dims` is a dictionary with two fields, `dims['l']` and `dims['q']`.
  These are the same fields as in the Matlab case. If the fields are omitted or
  empty, they default to 0.
  The argument `kwargs` can include the keywords
  + `feastol`, `abstol`, `reltol`, `feastol_inacc`, `abstol_innac`, and `reltol_inacc` for tolerance values,
  + `max_iters` for the maximum number of iterations,
  + the Booleans `verbose` and `mi_verbose`,
  + `bool_vars_idx`, a list of `int`s which index the boolean variables,
  + `int_vars_idx`, a list of `int`s which index the integer variables,
  + `mi_max_iters` for maximum number of branch and bound iterations (mixed integer problems only),
  + `mi_abs_eps` for the absolute tolerance between upper and lower bounds (mixed integer problems only), and
  + `mi_rel_eps` for the relative tolerance, (U-L)/L, between upper and lower bounds (mixed integer problems only).

  The arguments `A`, `b`, and `kwargs` are optional.

  The returned object is a dictionary containing the fields `solution['x']`, `solution['y']`, `solution['s']`, `solution['z']`, and `solution['info']`.
  The first four are Numpy arrays containing the relevant solution. The last field contains a dictionary with the same fields as the `info` struct in the MATLAB interface.



  [CVXPY](http://cvxpy.org) is a powerful Python modeling framework for
  convex optimization, similar to the MATLAB counterpart CVX. ECOS is one
  of the default solvers in CVXPY, so there is nothing special you have to
  do in order to use ECOS with CVXPY, besides specifying it as a solver.
  Here is a small
  [example](http://www.cvxpy.org/en/latest/tutorial/advanced/index.html#solve-method-options)
  from the CVXPY tutorial:

  ```py
  import cvxpy as cp


  x = cp.Variable(2)
  obj = cp.Minimize(cp.norm(x, 2) + cp.norm(x, 1))
  constraints = [x >= 2]
  prob = cp.Problem(obj, constraints)


  prob.solve(solver=cp.ECOS)
  print("optimal value with ECOS:", prob.value)
  ```


  The Python module contains two version numbers:

  1. `ecos.__version__`: This is the version of the Python wrapper for
     ECOS
  2. `ecos.__solver_version__`: This is the version of the underlying ECOS
     solver

  These two version numbers should typically agree, but they might not
  when a bug in the Python module has been fixed and nothing in the
  underlying C solver has changed. The major version numbers should agree,
  however.


  Because version-syncing ECOS and ECOS-Python can be tricky, the 2.0.7
  version did not incorporate some minor changes to ECOS. In an
  ill-advised move, the release was deleted in hopes it could be
  re-uploaded, despite plenty warnings stating otherwise.

  Instead, a post release has been made that contains identical content to
  the 2.0.7 release. Generally, `pip` should pick up the post release for
  2.0.7 and any dependencies such as `pip install "ecos>=2.0.5"` should still
  work as expected.


  When creating new versions of the Python wrapper, please use
  `bumpversion` to bump the version number and also remember to tag the
  commit so that CI is able to properly pick it up. See
  [Release](RELEASE.md) for more information.


  Starting with version 2.0.8, ecos-python will no longer support
  Python2.7. You may be able to download an [older
  version](https://github.com/embotech/ecos-python/releases/tag/2.0.7.post1)
  but moving forward we will no longer publish Python2 wheels for use.



  ECOS is distributed under the [GNU General Public License
  v3.0](http://www.gnu.org/copyleft/gpl.html). Other licenses may be
  available upon request from [embotech](http://www.embotech.com).






  The solver is essentially based on Lieven Vandenberghe's [CVXOPT](http://cvxopt.org) [ConeLP](http://www.ee.ucla.edu/~vandenbe/publications/coneprog.pdf) solver, although it differs in the particular way the linear systems are treated.

  The following people have been, and are, involved in the development and maintenance of ECOS:

  + Alexander Domahidi (principal developer)
  + Eric Chu (Python interface, unit tests)
  + Stephen Boyd (methods and maths)
  + Michael Grant (CVX interface)
  + Johan Löfberg (YALMIP interface)
  + João Felipe Santos, Iain Dunning (Julia interface)
  + Han Wang (ECOS branch and bound)

  The main technical idea behind ECOS is described in a short [paper](http://www.stanford.edu/~boyd/papers/ecos.html). More details are given in Alexander Domahidi's [PhD Thesis](http://e-collection.library.ethz.ch/view/eth:7611?q=domahidi) in Chapter 9.

  If you find ECOS useful, you can cite it using the following BibTex entry:

  ```
  @INPROCEEDINGS{bib:Domahidi2013ecos,
  author={Domahidi, A. and Chu, E. and Boyd, S.},
  booktitle={European Control Conference (ECC)},
  title={{ECOS}: {A}n {SOCP} solver for embedded systems},
  year={2013},
  pages={3071-3076}
  }
  ```


pkgId: 31a223b4ace41d1bd5ad7d867093ff833de316e9610c4cb1117e57b08bc45580
name: python-ecos-debuginfo
arch: x86_64
version: 2.0.12
epoch: 0
release: 1
summary: Debug information for package python-ecos
url: http://github.com/embotech/ecos
rpm_license: GPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-72ec0de5-9177-4023-b36a-537fcb3792fa
rpm_sourcerpm: python-ecos-2.0.12-1.src.rpm
location_href: 00009951-python-ecos/python-ecos-debuginfo-2.0.12-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-ecos.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: d5aea5a3b9bf64b3614423c5e6484243621792eb8ba6c6ea773b2cb9a2e718de
name: python-ecos-debugsource
arch: x86_64
version: 2.0.12
epoch: 0
release: 1
summary: Debug sources for package python-ecos
url: http://github.com/embotech/ecos
rpm_license: GPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-72ec0de5-9177-4023-b36a-537fcb3792fa
rpm_sourcerpm: python-ecos-2.0.12-1.src.rpm
location_href: 00009951-python-ecos/python-ecos-debugsource-2.0.12-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-ecos.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: ba92fb87e012bc76101169b7fefda14f4952a4597e7710039ca7322fb5e5f7fc
name: python-editor
arch: src
version: 1.3.0
epoch: 0
release: 1
summary: 🖋 Open the default text editor 🖋
url: https://pypi.org/project/editor/
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e65f21d5-229b-4a70-afc5-043cdf2fe253
location_href: 00009014-python-editor/python-editor-1.3.0-1.src.rpm
checksum_type: sha256
description:
  `editor` opens a text editor for an existing file, a new file, or a tempfile,
  blocks while the user edits text, then returns the results.

  You can specify a command line that runs the editor, but usually you leave it
  empty - in that case, `editor` uses the  the command line from the environment
  variable `VISUAL`, or if that's empty, the environment variable `EDITOR`, or if
  *that's* empty, either `Notepad` on Windows or `vi` elsewhere.



  If no filename is provided, a temporary file gets edited, and its contents
  returned.


      import editor

      MESSAGE = 'Insert comments below this line\n\n'
      comments = editor(text=MESSAGE)
      



  If a filename is provided, then it gets edited!

      import os

      FILE = 'file.txt'
      assert not os.path.exists(FILE)

      comments = editor(text=MESSAGE, filename=FILE)
      

      assert os.path.exists(FILE)

      
      comments2 = editor(filename=FILE, editor='emacs')


pkgId: c0f367646b1835d3e25b9898addb63bb148beead0e1bc89fac3c06736b8c477b
name: python-edx-ace
arch: src
version: 1.6.1
epoch: 0
release: 1
summary: Framework for Messaging
url: https://github.com/openedx/edx-ace
rpm_license: AGPL 3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fb2f3ad3-66a2-4608-bc88-67b519bc9e9e
location_href: 00013774-python-edx-ace/python-edx-ace-1.6.1-1.src.rpm
checksum_type: sha256
description:
  The `automated communication engine <https://edx-ace.readthedocs.io/en/latest/>`_, A.C.E. for short, is a Django app
  for messaging learners on the Open edX platform. This
  app can be installed in any Open edX project, but has only been tested with ``edx-platform``. Email delivery
  (via Sailthru and Django Email)
  are the currently supported delivery channels. In the future we may add support for other delivery channels such as push
  notifications.


pkgId: 50cd9c64b015895971a76d4b9e284a2481be37e3dd8e0ccc261ed27ea5f12bc5
name: python-edx-api-doc-tools
arch: src
version: 1.6.0
epoch: 0
release: 1
summary: Tools for writing and generating API documentation for edX REST APIs
url: https://github.com/edx/api-doc-tools
rpm_license: Apache Software License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7ef53c25-c9a1-45f9-9e89-808b42445d1f
location_href: 00013882-python-edx-api-doc-tools/python-edx-api-doc-tools-1.6.0-1.src.rpm
checksum_type: sha256
description:
  |pypi| |CI| |codecov| |readthedocs| |pyversions| |license|
  A toolkit for documenting REST APIs that are created with `DRF`_.
  The tools use `drf-yasg`_ (DRF, yet another Swagger generator) to generate an
  `OpenAPI Specification`_, which is a .json/.yaml file that describes your API.
  Additionally, this package makes it easy to configure your service to expose
  generated OpenAPI specification under `/api-docs.yaml` and to serve interactive
  documentation under `/api-docs`.
  This library was developed for use with `Open edX`_ services, but could be used
  to document any Django REST Framework API.


pkgId: eca349ac30daee890649531a2dbfa6559cfbc91c04ae3bea009153d0412dd506
name: python-edx-bulk-grades
arch: src
version: 1.0.1
epoch: 0
release: 1
summary: Support for bulk scoring and grading
url: https://github.com/openedx/edx-bulk-grades
rpm_license: AGPL 3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-af7f6e77-52ac-4b1d-b3ba-332e28afa8ea
location_href: 00013898-python-edx-bulk-grades/python-edx-bulk-grades-1.0.1-1.src.rpm
checksum_type: sha256
description:
  |pypi-badge| |travis-badge| |codecov-badge| |doc-badge| |pyversions-badge|
  |license-badge|
  Support for bulk scoring and grading. This adds models and an API for reading and modifying
  scores and grades in bulk.


pkgId: ac76e69cd0f5fd9d78d05ddec7f8042b751068c748891e71ef1f188671d3fd19
name: python-edx-completion
arch: src
version: 4.2.0
epoch: 0
release: 1
summary: A library for tracking completion of blocks by learners in edX courses.
url: https://github.com/edx/completion
rpm_license: AGPL 3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ec8d0a5a-0cf0-491b-aa5d-3a7ed2762788
location_href: 00013935-python-edx-completion/python-edx-completion-4.2.0-1.src.rpm
checksum_type: sha256
description:
  |pypi-badge| |CI| |codecov-badge| |doc-badge| |pyversions-badge|
  |license-badge|
  A library for tracking completion of blocks by learners in edX courses.
  Overview
  ________
  This repository provides a Django model `BlockCompletion` that is intended to be plugged into ``edx-platform``.  It
  provides various handlers and services for the recording of completion data.  It also provides a DRF API for submitting
  completion data in batches.


pkgId: c0e9923071af1b9e315926a9e3877db542be62233c49cb96b00bd32eafe684a0
name: python-edx-django-sites-extensions
arch: src
version: 4.0.0
epoch: 0
release: 1
summary: Custom extensions for the Django sites framework
url: https://github.com/edx/edx-django-sites-extensions
rpm_license: AGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-25fb8b4d-8cd9-463f-8239-40f6de271a12
location_href: 00013678-python-edx-django-sites-extensions/python-edx-django-sites-extensions-4.0.0-1.src.rpm
checksum_type: sha256
description:
  This package includes extensions to the Django "sites" framework
  used by Open edX Django IDAs (independently deployable applications).


pkgId: 3e12c0649500da2282bb40f6fe79445ec641e4bb02191b37b54f7e03a4965613
name: python-edx-django-sites-extensions-help
arch: noarch
version: 4.0.0
epoch: 0
release: 1
summary: Development documents and examples for edx-django-sites-extensions
url: https://github.com/edx/edx-django-sites-extensions
rpm_license: AGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-25fb8b4d-8cd9-463f-8239-40f6de271a12
rpm_sourcerpm: python-edx-django-sites-extensions-4.0.0-1.src.rpm
checksum_type: sha256
description:
  This package includes extensions to the Django "sites" framework
  used by Open edX Django IDAs (independently deployable applications).

location_href:
  00013678-python-edx-django-sites-extensions/python-edx-django-sites-extensions-help-4.0.0-1.noarch.rpm


pkgId: 9c1d79e8b41a078d3b32782db9fca87cd27d5468bfa05795515f497fd4ad0bd3
name: python-edx-django-utils
arch: src
version: 5.3.0
epoch: 0
release: 1
summary: EdX utilities for Django Application development.
url: https://github.com/openedx/edx-django-utils
rpm_license: Apache Software License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-dfce9e7d-bd2d-4e27-a9e6-e341dcaed9ab
location_href: 00012972-python-edx-django-utils/python-edx-django-utils-5.3.0-1.src.rpm
checksum_type: sha256
description:
  |pypi-badge| |ci-badge| |codecov-badge| |doc-badge| |pyversions-badge|
  |license-badge| |status-badge|
  EdX utilities for Django Application development.
  Note that some utilities may warrant their own repository. A judgement call
  needs to be made as to whether code properly belongs here or not. Please
  review with the Architecture Team if you have any questions.


pkgId: 75bd50bbb1b9121a5cf9adbafa68901e5bdcb78f388ada36a146f7bdb2deb0b7
name: python-edx-milestones
arch: src
version: 0.4.0
epoch: 0
release: 1
summary: Significant events module for Open edX
url: https://github.com/edx/edx-milestones
rpm_license: AGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f4395bda-89ac-4955-815f-9666fcdb95db
location_href: 00014000-python-edx-milestones/python-edx-milestones-0.4.0-1.src.rpm
checksum_type: sha256
description:
  edx-milestones (`milestones`) is a Django application which manages significant Course and/or Student events in the Open edX platform.


pkgId: 350dbb0674475af3c3dc54f3f2117ed7d9271d1dcf565e12fa9c63fcb84af55d
name: python-edx-organizations
arch: src
version: 6.11.1
epoch: 0
release: 1
summary: Organization management module for Open edX
url: https://github.com/edx/edx-organizations
rpm_license: AGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-10393ba5-1879-47ee-a74d-0b0e2fffcc6f
location_href: 00014013-python-edx-organizations/python-edx-organizations-6.11.1-1.src.rpm
checksum_type: sha256
description:
  edx-organizations (``organizations``) is a Django application
  responsible for managing the concept of Organizations in the Open edX
  platform. Organizations represent the entities responsible for creating
  and publishing Courses. In the future the scope and responsibilty of the
  Organization may evolve to include other aspects, such as related
  learners.


pkgId: b3aa42e1fee9f92f61b36224ba8062f9cbd2d68b6f3a948279b9ecd1a72cbb31
name: python-efel
arch: src
version: 4.1.63
epoch: 0
release: 1
summary: Electrophys Feature Extract Library (eFEL)
url: https://github.com/BlueBrain/eFEL
rpm_license: LGPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-81f49233-d865-46f1-a369-10979f3113b7
location_href: 00003561-python-efel/python-efel-4.1.63-1.src.rpm
checksum_type: sha256
description:
  The Electrophys Feature Extract Library (eFEL) allows neuroscientists to automatically extract features from time series data recorded from neurons (both in vitro and in silico). Examples are the action potential width and amplitude in voltage traces recorded during whole-cell patch clamp experiments. The user of the library provides a set of traces and selects the features to be calculated. The library will then extract the requested features and return the values to the user.


pkgId: b2ae418149b5915b1ad5771680c1fe2d991cd27c0ff4b421e89e59c34108994b
name: python-efel-debuginfo
arch: x86_64
version: 4.1.63
epoch: 0
release: 1
summary: Debug information for package python-efel
url: https://github.com/BlueBrain/eFEL
rpm_license: LGPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-81f49233-d865-46f1-a369-10979f3113b7
rpm_sourcerpm: python-efel-4.1.63-1.src.rpm
location_href: 00003561-python-efel/python-efel-debuginfo-4.1.63-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-efel.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: 4ac558c336fe274f38d8c9063cf2f4b0bddedb511cc7aa9e15667e6771aa36b1
name: python-efel-debugsource
arch: x86_64
version: 4.1.63
epoch: 0
release: 1
summary: Debug sources for package python-efel
url: https://github.com/BlueBrain/eFEL
rpm_license: LGPLv3
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-81f49233-d865-46f1-a369-10979f3113b7
rpm_sourcerpm: python-efel-4.1.63-1.src.rpm
location_href: 00003561-python-efel/python-efel-debugsource-4.1.63-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-efel.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: a6dbd7e75b5c5aef52eeaf0f645d4675bf2ce98d9253b638acc25e295e504a36
name: python-efficientnet
arch: src
version: 1.1.1
epoch: 0
release: 1
summary: EfficientNet model re-implementation. Keras and TensorFlow Keras.
url: https://github.com/qubvel/efficientnet
rpm_license: Apache License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7efcbc18-613e-4dd1-b6b2-b4445b480d51
location_href: 00011903-python-efficientnet/python-efficientnet-1.1.1-1.src.rpm
checksum_type: sha256
description:
  [![PyPI version](https://badge.fury.io/py/efficientnet.svg)](https://badge.fury.io/py/efficientnet) [![Downloads](https://pepy.tech/badge/efficientnet/month)](https://pepy.tech/project/efficientnet/month)

  This repository contains a Keras (and TensorFlow Keras) reimplementation of **EfficientNet**, a lightweight convolutional neural network architecture achieving the [state-of-the-art accuracy with an order of magnitude fewer parameters and FLOPS](https://arxiv.org/abs/1905.11946), on both ImageNet and
  five other commonly used transfer learning datasets.

  The codebase is heavily inspired by the [TensorFlow implementation](https://github.com/tensorflow/tpu/tree/master/models/official/efficientnet).


  There was a huge library update **24 of July 2019**. Now efficintnet works with both frameworks: `keras` and `tensorflow.keras`.
  If you have models, trained before that date, to load them, please, use efficientnet of 0.0.4 version (PyPI). You can roll back using `pip install -U efficientnet==0.0.4`.



   1. [About EfficientNet Models](#about-efficientnet-models)
   2. [Examples](#examples)
   3. [Models](#models)
   4. [Installation](#installation)
   5. [Frequently Asked Questions](#frequently-asked-questions)
   6. [Acknowledgements](#acknowledgements)



  EfficientNets rely on AutoML and compound scaling to achieve superior performance without compromising resource efficiency. The [AutoML Mobile framework](https://ai.googleblog.com/2018/08/mnasnet-towards-automating-design-of.html) has helped develop a mobile-size baseline network, **EfficientNet-B0**, which is then improved by the compound scaling method  to obtain EfficientNet-B1 to B7.

  <table border="0">
  <tr>
      <td>
      <img src="https://raw.githubusercontent.com/tensorflow/tpu/master/models/official/efficientnet/g3doc/params.png" width="100%" />
      </td>
      <td>
      <img src="https://raw.githubusercontent.com/tensorflow/tpu/master/models/official/efficientnet/g3doc/flops.png", width="90%" />
      </td>
  </tr>
  </table>

  EfficientNets achieve state-of-the-art accuracy on ImageNet with an order of magnitude better efficiency:

  * In high-accuracy regime, EfficientNet-B7 achieves the state-of-the-art 84.4% top-1 / 97.1% top-5 accuracy on ImageNet with 66M parameters and 37B FLOPS. At the same time, the model is 8.4x smaller and 6.1x faster on CPU inference than the former leader, [Gpipe](https://arxiv.org/abs/1811.06965).

  * In middle-accuracy regime, EfficientNet-B1 is 7.6x smaller and 5.7x faster on CPU inference than [ResNet-152](https://arxiv.org/abs/1512.03385), with similar ImageNet accuracy.

  * Compared to the widely used [ResNet-50](https://arxiv.org/abs/1512.03385), EfficientNet-B4 improves the top-1 accuracy from 76.3% of ResNet-50 to 82.6% (+6.3%), under similar FLOPS constraints.



  * *Initializing the model*:

  ```python



  import efficientnet.keras as efn

  model = efn.EfficientNetB0(weights='imagenet')  # or weights='noisy-student'

  ```

  * *Loading the pre-trained weights*:

  ```python



  import efficientnet.tfkeras
  from tensorflow.keras.models import load_model

  model = load_model('path/to/model.h5')
  ```

  See the complete example of loading the model and making an inference in the Jupyter notebook [here](https://github.com/qubvel/efficientnet/blob/master/examples/inference_example.ipynb).



  The performance of each model variant using the pre-trained weights converted from checkpoints provided by the authors is as follows:

  | Architecture   | @top1* Imagenet| @top1* Noisy-Student|
  | -------------- | :----: |:---:|
  | EfficientNetB0 | 0.772  |0.788|
  | EfficientNetB1 | 0.791  |0.815|
  | EfficientNetB2 | 0.802  |0.824|
  | EfficientNetB3 | 0.816  |0.841|
  | EfficientNetB4 | 0.830  |0.853|
  | EfficientNetB5 | 0.837  |0.861|
  | EfficientNetB6 | 0.841  |0.864|
  | EfficientNetB7 | 0.844  |0.869|

  **\*** - topK accuracy score for converted models (imagenet `val` set)





  * `Keras >= 2.2.0` / `TensorFlow >= 1.12.0`
  * `keras_applications >= 1.0.7`
  * `scikit-image`



  ```bash
  $ pip install -U git+https://github.com/qubvel/efficientnet
  ```



  PyPI stable release

  ```bash
  $ pip install -U efficientnet
  ```

  PyPI latest release (with keras and tf.keras support)

  ```bash
  $ pip install -U --pre efficientnet
  ```



  * **How can I convert the original TensorFlow checkpoints to Keras HDF5?**

  Pick the target directory (like `dist`) and run the [converter script](./scripts) from the repo directory as follows:

  ```bash
  $ ./scripts/convert_efficientnet.sh --target_dir dist
  ```

  You can also optionally create the virtual environment with all the dependencies installed by adding `--make_venv=true` and operate in a self-destructing temporary location instead of the target directory by setting `--tmp_working_dir=true`.


  I would like to thanks community members who actively contribute to this repository:

  1) Sasha Illarionov ([@sdll](https://github.com/sdll)) for preparing automated script for weights conversion
  2) Björn Barz ([@Callidior](https://github.com/Callidior)) for model code adaptation for keras and tensorflow.keras frameworks


pkgId: d4e049a532c8f34e44c836a301c1641a870d4039449a63dbc7332ad32ba4a8f4
name: python-elastic-apm
arch: src
version: 6.15.1
epoch: 0
release: 1
summary: The official Python module for Elastic APM
url: https://github.com/elastic/apm-agent-python
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-c2c8544e-4e14-4a89-ba48-dcbc56e90a5b
location_href: 00009902-python-elastic-apm/python-elastic-apm-6.15.1-1.src.rpm
checksum_type: sha256
description:
  This is the official Python module for Elastic APM.
  It provides full out-of-the-box support for many of the popular frameworks,
  including Django, and Flask. Elastic APM is also easy to adapt for most
  WSGI-compatible web applications via `custom integrations`_.
  Your application doesn't live on the web? No problem! Elastic APM is easy to use in
  any Python application.
  Read the documentation_, including instructions on `running the tests locally`_.
  If you're interested in contributing, `start here!`_


pkgId: d9093703b24a97e17617f159fd937b05c4bc162247bba6f1f61c7afaa2938c08
name: python-elasticsearch-async
arch: src
version: 6.2.0
epoch: 0
release: 1
summary: Async backend for elasticsearch-py
url: https://github.com/elastic/elasticsearch-py-async
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-21b18612-c04d-4f9f-8e31-b63751765cf2
location_href: 00013739-python-elasticsearch-async/python-elasticsearch-async-6.2.0-1.src.rpm
checksum_type: sha256
description:
  This is an adapter for `elasticsearch-py`_ providing a transport layer based on
  Python's `asyncio`_ module. All API calls now return a future wrapping the
  response.
  Sniffing (when requested) is also done via a scheduled coroutine.
  Example for python 3.5+
      import asyncio
      from elasticsearch_async import AsyncElasticsearch
      client = AsyncElasticsearch(hosts=['localhost', 'other-host'])
      async def print_info():
          info = await client.info()
          print(info)
      loop = asyncio.get_event_loop()
      loop.run_until_complete(print_info())
      loop.run_until_complete(client.transport.close())
      loop.close()
  Example for python 3.4
      import asyncio
      from elasticsearch_async import AsyncElasticsearch
      client = AsyncElasticsearch(hosts=['localhost', 'other-host'])
      @asyncio.coroutine
      def print_info():
          info = yield from client.info()
          print(info)
      loop = asyncio.get_event_loop()
      loop.run_until_complete(print_info())
      loop.run_until_complete(client.transport.close())
      loop.close()
  Example with SSL Context
      import asyncio
      from elasticsearch_async import AsyncElasticsearch
      from elasticsearch.connection.http_urllib3 import create_ssl_context
      context = create_ssl_context(cafile="/certs/ca/ca.crt")
      client = AsyncElasticsearch(
          hosts=['elasticsearch-xpack'],
          ssl_context=context,
          http_auth=('elastic', 'changeme')
      )
      @asyncio.coroutine
      def print_info():
          info = yield from client.info()
          print(info)
      loop = asyncio.get_event_loop()
      loop.run_until_complete(print_info())
      loop.run_until_complete(client.transport.close())
      loop.close()
  ``AsyncElasticsearch`` introduces one extra parameter ``loop`` which can be
  used to pass in an event loop you wish the client to use. By default
  ``asyncio.get_event_loop()`` will be used.


pkgId: 3cbd91d0e3d95e8fff8557990ad3c7db79725271bba98379f01f92e6ae6393f3
name: python-elasticsearch-dbapi
arch: src
version: 0.2.10
epoch: 0
release: 1
summary: A DBAPI and SQLAlchemy dialect for Elasticsearch
url: http://preset.io
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d46936a3-d91f-4d21-9b1f-1637b91839d5
location_href: 00012589-python-elasticsearch-dbapi/python-elasticsearch-dbapi-0.2.10-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://github.com/preset-io/elasticsearch-dbapi/workflows/Python/badge.svg)](https://github.com/preset-io/elasticsearch-dbapi/actions)
  [![PyPI version](https://badge.fury.io/py/elasticsearch-dbapi.svg)](https://badge.fury.io/py/elasticsearch-dbapi)
  [![Coverage Status](https://codecov.io/github/preset-io/elasticsearch-dbapi/coverage.svg?branch=master)](https://codecov.io/github/preset-io/elasticsearch-dbapi)


  `elasticsearch-dbapi` Implements a DBAPI (PEP-249) and SQLAlchemy dialect,
  that enables SQL access on elasticsearch clusters for query only access.

  On Elastic Elasticsearch:
  Uses Elastic X-Pack [SQL API](https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-sql.html)

  On AWS ES, opendistro Elasticsearch:
  [Open Distro SQL](https://opendistro.github.io/for-elasticsearch-docs/docs/sql/)

  This library supports Elasticsearch 7.X versions.



  ```bash
  $ pip install elasticsearch-dbapi
  ```

  To install support for AWS Elasticsearch Service / [Open Distro](https://opendistro.github.io/for-elasticsearch/features/SQL%20Support.html):

  ```bash
  $ pip install elasticsearch-dbapi[opendistro]
  ```





  ```python
  from es.elastic.api import connect

  conn = connect(host='localhost')
  curs = conn.cursor()
  curs.execute(
      "select * from flights LIMIT 10"
  )
  print([row for row in curs])
  ```



  ```python
  from sqlalchemy.engine import create_engine

  engine = create_engine("elasticsearch+http://localhost:9200/")
  rows = engine.connect().execute(
      "select * from flights LIMIT 10"
  )
  print([row for row in rows])
  ```



  ```python
  from sqlalchemy import func, select
  from sqlalchemy.engine import create_engine
  from sqlalchemy.schema import MetaData, Table


  engine = create_engine("elasticsearch+http://localhost:9200/")
  logs = Table("flights", MetaData(bind=engine), autoload=True)
  count = select([func.count("*")], from_obj=logs).scalar()
  print(f"COUNT: {count}")
  ```



  ```python

  from sqlalchemy.engine import create_engine
  from sqlalchemy.schema import Table, MetaData

  engine = create_engine("elasticsearch+http://localhost:9200/")
  logs = Table("flights", MetaData(bind=engine), autoload=True)
  print(engine.table_names())

  metadata = MetaData()
  metadata.reflect(bind=engine)
  print([table for table in metadata.sorted_tables])
  print(logs.columns)
  ```



  [elasticsearch-py](https://elasticsearch-py.readthedocs.io/en/master/index.html)
  is used to establish connections and transport, this is the official
  elastic python library. `Elasticsearch` constructor accepts multiple optional parameters
  that can be used to properly configure your connection on aspects like security, performance
  and high availability. These optional parameters can be set at the connection string, for
  example:

   ```bash
      elasticsearch+http://localhost:9200/?http_compress=True&timeout=100
  ```
  will set transport to use gzip (http_compress) and timeout to 10 seconds.

  For more information on configuration options, look at `elasticsearch-py`’s documentation:
  - [Transport Options](https://elasticsearch-py.readthedocs.io/en/master/connection.html#transport)
  - [HTTP tranport](https://elasticsearch-py.readthedocs.io/en/master/transports.html#urllib3httpconnection)

  The connection string follows RFC-1738, to support multiple nodes you should use `sniff_*` parameters



  By default the maximum number of rows which get fetched by a single query
  is limited to 10000. This can be adapted through the `fetch_size`
  parameter:

  ```python
  from es.elastic.api import connect

  conn = connect(host="localhost", fetch_size=1000)
  curs = conn.cursor()
  ```

  If more than 10000 rows should get fetched then
  [max_result_window](https://www.elastic.co/guide/en/elasticsearch/reference/7.x/index-modules.html#dynamic-index-settings)
  has to be adapted as well.



  By default, elasticsearch query time zone defaults to `Z` (UTC). This can be adapted through the `time_zone`
  parameter:

  ```python
  from es.elastic.api import connect

  conn = connect(host="localhost", time_zone="Asia/Shanghai")
  curs = conn.cursor()
  ```



  To run unittest launch elasticsearch and kibana (kibana is really not required but is a nice to have)

  ```bash
  $ docker-compose up -d
  $ nosetests -v
  ```



  AWS ES exposes the opendistro SQL plugin, and it follows a different SQL dialect.
  Using the `odelasticsearch` driver:

  ```python
  from sqlalchemy.engine import create_engine

  engine = create_engine(
      "odelasticsearch+https://search-SOME-CLUSTER.us-west-2.es.amazonaws.com:443/"
  )
  rows = engine.connect().execute(
      "select count(*), Carrier from flights GROUP BY Carrier"
  )
  print([row for row in rows])
  ```

  Or using DBAPI:
  ```python
  from es.opendistro.api import connect

  conn = connect(host='localhost',port=9200,path="", scheme="http")

  curs = conn.cursor().execute(
      "select * from flights LIMIT 10"
  )

  print([row for row in curs])
  ```



  Basic authentication is configured as expected on the <username>,<password> fields of the URI

  ```python
  from sqlalchemy.engine import create_engine

  engine = create_engine(
      "odelasticsearch+https://my_user:my_password@search-SOME-CLUSTER.us-west-2.es.amazonaws.com:443/"
  )
  ```

  IAM AWS Authentication keys are passed on the URI basic auth location, and by setting `aws_keys`

  Query string keys are:

  - aws_keys
  - aws_region

  ```python
  from sqlalchemy.engine import create_engine

  engine = create_engine(
      "odelasticsearch+https://<AWS_ACCESS_KEY>:<AWS_SECRET_KEY>@search-SOME-CLUSTER.us-west-2.es.amazonaws.com:443/?aws_keys=1&&aws_region=<AWS_REGION>"
  )
  ```

  IAM AWS profile is configured has a query parameter name `aws_profile` on the URI. The value for the key provides the AWS region

  ```python
  from sqlalchemy.engine import create_engine

  engine = create_engine(
      "odelasticsearch+https://search-SOME-CLUSTER.us-west-2.es.amazonaws.com:443/?aws_profile=us-west-2"
  )
  ```

  Using the new SQL engine:

  Opendistro 1.13.0 brings (enabled by default) a new SQL engine, with lots of improvements and fixes.
  Take a look at the [release notes](https://github.com/opendistro-for-elasticsearch/sql/blob/develop/docs/dev/NewSQLEngine.md)

  This DBAPI has to behave slightly different for SQL v1 and SQL v2, by default we comply with v1,
  to enable v2 support, pass `v2=true` has a query parameter.

  ```
  odelasticsearch+https://search-SOME-CLUSTER.us-west-2.es.amazonaws.com:443/?aws_profile=us-west-2&v2=true
  ```

  To connect to the provided Opendistro ES on `docker-compose` use the following URI:
  `odelasticsearch+https://admin:admin@localhost:9400/?verify_certs=False`



  This library does not yet support the following features:

  - Array type columns are not supported. Elaticsearch SQL does not support them either.
  SQLAlchemy `get_columns` will exclude them.
  - `object` and `nested` column types are not well supported and are converted to strings
  - Indexes that whose name start with `.`
  - GEO points are not currently well-supported and are converted to strings

  - AWS ES (opendistro elascticsearch) is supported (still beta), known limitations are:
    * You are only able to `GROUP BY` keyword fields (new [experimental](https://github.com/opendistro-for-elasticsearch/sql#experimental)
   opendistro SQL already supports it)
    * Indices with dots are not supported (indices like 'audit_log.2021.01.20'),
    on these cases we recommend the use of aliases


pkgId: 7fca3a17c7395879f75dc18a89e68cfbc99c38756d36d3802775a90b59ad2000
name: python-elasticsearch-dsl
arch: src
version: 7.4.1
epoch: 0
release: 1
summary: Python client for Elasticsearch
url: https://github.com/elasticsearch/elasticsearch-dsl-py
rpm_license: Apache-2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-b6fd8d8a-25a6-4f28-8474-43bd9cd5d333
location_href: 00009454-python-elasticsearch-dsl/python-elasticsearch-dsl-7.4.1-1.src.rpm
checksum_type: sha256
description:
  Elasticsearch DSL is a high-level library whose aim is to help with writing and
  running queries against Elasticsearch. It is built on top of the official
  low-level client (`elasticsearch-py <https://github.com/elastic/elasticsearch-py>`_).
  It provides a more convenient and idiomatic way to write and manipulate
  queries. It stays close to the Elasticsearch JSON DSL, mirroring its
  terminology and structure. It exposes the whole range of the DSL from Python
  either directly using defined classes or a queryset-like expressions.
  It also provides an optional wrapper for working with documents as Python
  objects: defining mappings, retrieving and saving documents, wrapping the
  document data in user-defined classes.
  To use the other Elasticsearch APIs (eg. cluster health) just use the
  underlying client.


pkgId: ee66910b191fcca7aab15b7af27e2feaf8721542b9dbf728936868aabcffb6fd
name: python-elasticsearch2
arch: src
version: 2.5.1
epoch: 0
release: 1
summary: Python client for Elasticsearch
url: https://github.com/elastic/elasticsearch-py
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-280d1698-4da8-478f-b347-a1ebecb9c4cc
location_href: 00011724-python-elasticsearch2/python-elasticsearch2-2.5.1-1.src.rpm
checksum_type: sha256
description:
  Official low-level client for Elasticsearch. Its goal is to provide common
  ground for all Elasticsearch-related code in Python; because of this it tries
  to be opinion-free and very extendable.
  For a more high level client library with more limited scope, have a look at
  `elasticsearch-dsl`_ - a more pythonic library sitting on top of
  ``elasticsearch-py``.
  It provides a more convenient and idiomatic way to write and manipulate
  `queries`_. It stays close to the Elasticsearch JSON DSL, mirroring its
  terminology and structure while exposing the whole range of the DSL from Python
  either directly using defined classes or a queryset-like expressions.
  It also provides an optional `persistence layer`_ for working with documents as
  Python objects in an ORM-like fashion: defining mappings, retrieving and saving
  documents, wrapping the document data in user-defined classes.


pkgId: 7a846c90f3e7442b2df7bc8b7eaffa4dcc4d55dc7e7328567e4f0f857aa22088
name: python-elementpath
arch: src
version: 4.1.0
epoch: 0
release: 1
summary: XPath 1.0/2.0/3.0/3.1 parsers and selectors for ElementTree and lxml
url: https://github.com/sissaschool/elementpath
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-9aa7ae08-ff73-4ff1-83e4-0b74c3140933
location_href: 00009656-python-elementpath/python-elementpath-4.1.0-1.src.rpm
checksum_type: sha256
description:
  You can install the package with *pip* in a Python 3.7+ environment::
      pip install elementpath
  For using it import the package and apply the selectors on ElementTree nodes:
  >>> import elementpath
  >>> from xml.etree import ElementTree
  >>> root = ElementTree.XML('<A><B1/><B2><C1/><C2/><C3/></B2></A>')
  >>> elementpath.select(root, '/A/B2/*')
  [<Element 'C1' at ...>, <Element 'C2' at ...>, <Element 'C3' at ...>]
  The *select* API provides the standard XPath result format that is a list or an elementary
  datatype's value. If you want only to iterate over results you can use the generator function
  *iter_select* that accepts the same arguments of *select*.
  The selectors API works also using XML data trees based on the `lxml.etree <http://lxml.de>`_
  library:
  >>> import elementpath
  >>> import lxml.etree as etree
  >>> root = etree.XML('<A><B1/><B2><C1/><C2/><C3/></B2></A>')
  >>> elementpath.select(root, '/A/B2/*')
  [<Element C1 at ...>, <Element C2 at ...>, <Element C3 at ...>]
  When you need to apply the same XPath expression to several XML data you can also use the
  *Selector* class, creating an instance and then using it to apply the path on distinct XML
  data:
  >>> import elementpath
  >>> import lxml.etree as etree
  >>> selector = elementpath.Selector('/A/*/*')
  >>> root = etree.XML('<A><B1/><B2><C1/><C2/><C3/></B2></A>')
  >>> selector.select(root)
  [<Element C1 at ...>, <Element C2 at ...>, <Element C3 at ...>]
  >>> root = etree.XML('<A><B1><C0/></B1><B2><C1/><C2/><C3/></B2></A>')
  >>> selector.select(root)
  [<Element C0 at ...>, <Element C1 at ...>, <Element C2 at ...>, <Element C3 at ...>]
  Public API classes and functions are described into the
  `elementpath manual on the "Read the Docs" site <http://elementpath.readthedocs.io/en/latest/>`_.
  For default the XPath 2.0 is used. If you need XPath 1.0 parser provide the *parser* argument:
  >>> from elementpath import select, XPath1Parser
  >>> from xml.etree import ElementTree
  >>> root = ElementTree.XML('<A><B1/><B2><C1/><C2/><C3/></B2></A>')
  >>> select(root, '/A/B2/*', parser=XPath1Parser)
  [<Element 'C1' at ...>, <Element 'C2' at ...>, <Element 'C3' at ...>]
  For XPath 3.0/3.1 import the parser from *elementpath.xpath3* subpackage, that is not loaded
  for default:
  >>> from elementpath.xpath3 import XPath3Parser
  >>> select(root, 'math:atan(1.0e0)', parser=XPath3Parser)
  0.7853981633974483
  Note: *XPath3Parser* is an alias of *XPath31Parser*.
  If you need only XPath 3.0 you can also use a more specific subpackage,
  avoiding the loading of XPath 3.1 implementation:
  >>> from elementpath.xpath30 import XPath30Parser
  >>> select(root, 'math:atan(1.0e0)', parser=XPath30Parser)
  0.7853981633974483


pkgId: 8aa5482d2377f0413f416975d5cfb02fe8e7d1a75f22f6bd8b47728e5035051a
name: python-elephant
arch: src
version: 0.12.0
epoch: 0
release: 1
summary: Elephant is a package for analysis of electrophysiology data in Python
url: http://python-elephant.org
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5c76eae8-8d33-4601-857b-8c20ebd6e48b
location_href: 00003562-python-elephant/python-elephant-0.12.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/NeuralEnsemble/elephant.svg?branch=master)](https://travis-ci.org/NeuralEnsemble/elephant)
  [![Coverage Status](https://coveralls.io/repos/github/NeuralEnsemble/elephant/badge.svg?branch=master)](https://coveralls.io/github/NeuralEnsemble/elephant?branch=master)
  [![Documentation Status](https://readthedocs.org/projects/elephant/badge/?version=latest)](https://elephant.readthedocs.io/en/latest/?badge=latest)
  [![![PyPi]](https://img.shields.io/pypi/v/elephant)](https://pypi.org/project/elephant/)
  [![Statistics](https://img.shields.io/pypi/dm/elephant)](https://seladb.github.io/StarTrack-js/#/preload?r=neuralensemble,elephant)
  [![Gitter](https://badges.gitter.im/python-elephant/community.svg)](https://gitter.im/python-elephant/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
  [![DOI Latest Release](https://zenodo.org/badge/10311278.svg)](https://zenodo.org/badge/latestdoi/10311278)
  [![tests](https://github.com/NeuralEnsemble/elephant/actions/workflows/CI.yml/badge.svg)](https://github.com/NeuralEnsemble/elephant/actions/workflows/CI.yml)
  [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/6191/badge)](https://bestpractices.coreinfrastructure.org/projects/6191)

  *Elephant* package analyses all sorts of neurophysiological data:
  spike trains, LFP, analog signals. The input-output data format is either
  [Neo](https://github.com/NeuralEnsemble/python-neo), Quantity or Numpy array.




  * Documentation: https://elephant.readthedocs.io/en/latest/
  * Mailing list: https://groups.google.com/group/neuralensemble




  Viziphant package (https://github.com/INM-6/viziphant) is developed by Elephant
  team for plotting and visualization of the output of Elephant functions in a
  few lines of code.




  Modified BSD License, see [LICENSE.txt](LICENSE.txt) for details.




  :copyright: 2014-2023 by the [Elephant team](doc/authors.rst).




  See [acknowledgments](doc/acknowledgments.rst).




  See [citations](doc/citation.rst).


pkgId: ef2f57ef48c75e61a06948cd1cf41b2691541505fce5a3b41abd4b9395881de2
name: python-elephant-debuginfo
arch: x86_64
version: 0.12.0
epoch: 0
release: 1
summary: Debug information for package python-elephant
url: http://python-elephant.org
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-5c76eae8-8d33-4601-857b-8c20ebd6e48b
rpm_sourcerpm: python-elephant-0.12.0-1.src.rpm
location_href: 00003562-python-elephant/python-elephant-debuginfo-0.12.0-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug information for package python-elephant.
  Debug information is useful when developing applications that use this
  package or when debugging this package.


pkgId: cf4b1a5b9c2c9bf80f21e3e66051c61a05a6b869acc3bc416f1644bf305fef20
name: python-elephant-debugsource
arch: x86_64
version: 0.12.0
epoch: 0
release: 1
summary: Debug sources for package python-elephant
url: http://python-elephant.org
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Development/Debug
rpm_buildhost: resalloc-5c76eae8-8d33-4601-857b-8c20ebd6e48b
rpm_sourcerpm: python-elephant-0.12.0-1.src.rpm
location_href: 00003562-python-elephant/python-elephant-debugsource-0.12.0-1.x86_64.rpm
checksum_type: sha256
description:
  This package provides debug sources for package python-elephant.
  Debug sources are useful when developing applications that use this
  package or when debugging this package.


pkgId: 4864fbffbe3aa8836a02186633f8b249e7093c24f116383debe777f311432c5a
name: python-email-validator
arch: src
version: 1.3.1
epoch: 0
release: 1
summary: A robust email address syntax and deliverability validation library.
url: https://github.com/JoshData/python-email-validator
rpm_license: CC0 (copyright waived)
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-041eff91-643d-4b49-9be7-8e9d0db0a64d
location_href: 00003564-python-email-validator/python-email-validator-1.3.1-1.src.rpm
checksum_type: sha256
description:
  A robust email address syntax and deliverability validation library for
  Python by [Joshua Tauberer](https://joshdata.me).
  This library validates that a string is of the form `name@example.com`. This is
  the sort of validation you would want for an email-based login form on
  a website.
  Key features:
  * Checks that an email address has the correct syntax --- good for
    login forms or other uses related to identifying users.
  * Gives friendly error messages when validation fails (appropriate to show
    to end users).
  * (optionally) Checks deliverability: Does the domain name resolve? And you can override the default DNS resolver.
  * Supports internationalized domain names and (optionally)
    internationalized local parts, but blocks unsafe characters.
  * Normalizes email addresses (super important for internationalized
    addresses! see below).
  The library is NOT for validation of the To: line in an email message
  (e.g. `My Name <my@address.com>`), which
  [flanker](https://github.com/mailgun/flanker) is more appropriate for.
  And this library does NOT permit obsolete forms of email addresses, so
  if you need strict validation against the email specs exactly, use
  [pyIsEmail](https://github.com/michaelherold/pyIsEmail).
  This library is tested with Python 3.6+ but should work in earlier versions:
  [![Build Status](https://app.travis-ci.com/JoshData/python-email-validator.svg?branch=main)](https://app.travis-ci.com/JoshData/python-email-validator)


pkgId: 1e254f20dfa698940ad63dd51a5e4eea816beaffe3bd0894e38acceb77c868c0
name: python-embeddings
arch: src
version: 0.0.8
epoch: 0
release: 1
summary: Pretrained word embeddings in Python.
url: https://github.com/vzhong/embeddings
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-3f34c6c7-d950-433e-94b4-cb9fac640785
location_href: 00009622-python-embeddings/python-embeddings-0.0.8-1.src.rpm
checksum_type: sha256
description:
  Embeddings is a python package that provides pretrained word embeddings for natural language processing and machine learning.
  Instead of loading a large file to query for embeddings, ``embeddings`` is backed by a database and fast to load and query:
      >>> %timeit GloveEmbedding('common_crawl_840', d_emb=300)
      100 loops, best of 3: 12.7 ms per loop
      >>> %timeit GloveEmbedding('common_crawl_840', d_emb=300).emb('canada')
      100 loops, best of 3: 12.9 ms per loop
      >>> g = GloveEmbedding('common_crawl_840', d_emb=300)
      >>> %timeit -n1 g.emb('canada')
      1 loop, best of 3: 38.2 µs per loop


pkgId: 6f5486aa7251de132811b612fa9dd4155d90cd7d299bebf636bce1cd3f65d24b
name: python-emcee
arch: src
version: 3.1.4
epoch: 0
release: 1
summary: The Python ensemble sampling toolkit for MCMC
url: https://emcee.readthedocs.io
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a6d2eb76-be96-410a-a933-f3ba9bce26ab
location_href: 00003566-python-emcee/python-emcee-3.1.4-1.src.rpm
checksum_type: sha256
description:
  **The Python ensemble sampling toolkit for affine-invariant MCMC**
  emcee is a stable, well tested Python implementation of the affine-invariant
  ensemble sampler for Markov chain Monte Carlo (MCMC)
  proposed by
  `Goodman & Weare (2010) <http://cims.nyu.edu/~weare/papers/d13.pdf>`_.
  The code is open source and has
  already been used in several published projects in the Astrophysics
  literature.


pkgId: 4b20833831cec5ab19699c4315954eba4ae1a66cce6260e64b8cf7ab95274955
name: python-empyrical
arch: src
version: 0.5.5
epoch: 0
release: 1
url: https://github.com/quantopian/empyrical
rpm_license: Apache License, Version 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ff3737e5-2356-403e-89fe-8c7f779ae71f
location_href: 00012290-python-empyrical/python-empyrical-0.5.5-1.src.rpm
checksum_type: sha256
summary:
  empyrical is a Python library with performance and risk statistics commonly used in quantitative finance

description:
  empyrical is a Python library with performance and risk
  statistics commonly used in quantitative finance by `Quantopian Inc`_.

  .. _Quantopian Inc: https://www.quantopian.com
  .. _Zipline: https://zipline.io
  .. _pyfolio: https://quantopian.github.io/pyfolio/


pkgId: fa2416aca966dd14e61be22248d4658f6a52cb7fe2be0a5e5ce23e0fcbc7b9c0
name: python-enthought-sphinx-theme
arch: src
version: 0.7.2
epoch: 0
release: 1
summary: Sphinx theme for Enthought products
url: https://github.com/enthought/enthought-sphinx-theme
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5dedea2b-f6cc-46bf-b765-5f5889b1209c
location_href: 00003572-python-enthought-sphinx-theme/python-enthought-sphinx-theme-0.7.2-1.src.rpm
checksum_type: sha256
description:
  `Sphinx <http://sphinx-doc.org>`_ theme for `Enthought projects
  <http://www.enthought.com>`_, derived from the `Scipy theme
  <https://github.com/scipy/scipy-sphinx-theme>`_.


pkgId: 45a90734b2f631a601cc8d901c7161204355d53c5fdca815624681315f17402c
name: python-entrypoint2
arch: src
version: 1.1
epoch: 0
release: 1
summary: easy to use command-line interface for python modules
url: https://github.com/ponty/entrypoint2
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-924d50ec-3b95-409a-8aac-df68ae829113
location_href: 00011031-python-entrypoint2/python-entrypoint2-1.1-1.src.rpm
checksum_type: sha256
description:
  easy to use command-line interface for Python modules

  home: https://github.com/ponty/entrypoint2/tree/1.1


pkgId: cbf2dc4207ea4d061606c7128489bc54e8ba71561ee1e1731f264784023efb7e
name: python-enturclient
arch: src
version: 0.2.4
epoch: 0
release: 1
summary: An API client for public transport data from Entur.
url: https://github.com/hfurubotten/enturclient
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a21a693a-89c3-4466-bbe3-f58fbcc58401
location_href: 00003573-python-enturclient/python-enturclient-0.2.4-1.src.rpm
checksum_type: sha256
description:
  Python client for fetching estimated departures from stop places in Norway from [`entur.org`](https://developer.entur.org) API. Information about stop places, platforms and real-time departures.

  [![PyPI version fury.io][pypi-version-badge]][pypi-enturclient]
  [![PyPI pyversions][py-versions-badge]][pypi-enturclient]

  [![Buy me a coffee][buymeacoffee-shield]][buymeacoffee]



  ```python
  import aiohttp
  import asyncio
  from enturclient import EnturPublicTransportData

  API_CLIENT_ID = 'awesome_company - my_application'

  async def print_bergen_train_delay():
      async with aiohttp.ClientSession() as client:
          stops = ['NSR:StopPlace:548']
          quays = ['NSR:Quay:48550']

          data = EnturPublicTransportData(
              client_name=API_CLIENT_ID, # Required
              stops=stops,
              quays=quays,
              omit_non_boarding=True,
              number_of_departures=5,
              web_session=client) # recommended argument

          await data.update()

          bergen_train = data.get_stop_info('NSR:StopPlace:548')
          bergen_train_delay = bergen_train.estimated_calls[0].delay_in_min

          print(bergen_train_delay)

  asyncio.run(print_bergen_train_delay())
  ```



  [Entur's travel planer](https://en-tur.no) has a map of all stops used in Norway. Use the map to find the stops you're interested in. When you have found one of your stops, click on it, and hit "Se alle avganger".

  Now the web browser should contain an URL with the id in it. Such as this:
  `https://en-tur.no/nearby-stop-place-detail?id=NSR:StopPlace:32376`

  The stop id is the content after `id=` parameter in the url. Copy paste this into the configuration.

  It's also possible to use the [National Stop Register (NSR)](https://stoppested.entur.org).
  Find your stop in the map, click on it and then again at the name. You have to zoom quite a bit in before the stops shows in the map. Information about the stop place, including the stop and quay ids will pop up on the side.

  [buymeacoffee-shield]: https://www.buymeacoffee.com/assets/img/guidelines/download-assets-sm-2.svg
  [buymeacoffee]: https://www.buymeacoffee.com/heine
  [pypi-enturclient]: https://pypi.org/project/enturclient/
  [pypi-version-badge]: https://badge.fury.io/py/enturclient.svg
  [py-versions-badge]: https://img.shields.io/pypi/pyversions/enturclient.svg


pkgId: 685fe993657beed68f20ee210f3174aa555a512ee8b2d7ea1108bb21c3dc6306
name: python-enum-compat
arch: src
version: 0.0.3
epoch: 0
release: 1
summary: enum/enum34 compatibility package
url: https://github.com/jstasiak/enum-compat
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bda0a331-e471-42a4-ab67-834b3f20a232
location_href: 00009992-python-enum-compat/python-enum-compat-0.0.3-1.src.rpm
checksum_type: sha256
description:
  This is a virtual package, its whole purpose is to install enum34 on
  Python older than 3.4. On Python 3.4+ it's a no-op.


pkgId: 3544bb34c587f7f3f445067cd1e1f494433dc279ecd62aa650cd5ad36ffdc91a
name: python-environs
arch: src
version: 9.5.0
epoch: 0
release: 1
summary: simplified environment variable parsing
url: https://github.com/sloria/environs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2b9c19f8-b3c5-468c-b9a6-5e1b3da66d6d
location_href: 00010070-python-environs/python-environs-9.5.0-1.src.rpm
checksum_type: sha256
description:
  [![Latest version](https://badgen.net/pypi/v/environs)](https://pypi.org/project/environs/)
  [![Build Status](https://dev.azure.com/sloria/sloria/_apis/build/status/sloria.environs?branchName=master)](https://dev.azure.com/sloria/sloria/_build/latest?definitionId=12&branchName=master)
  [![marshmallow 3 compatible](https://badgen.net/badge/marshmallow/3)](https://marshmallow.readthedocs.io/en/latest/upgrading.html)
  [![Black code style](https://badgen.net/badge/code%20style/black/000)](https://github.com/ambv/black)

  **environs** is a Python library for parsing environment variables.
  It allows you to store configuration separate from your code, as per
  [The Twelve-Factor App](https://12factor.net/config) methodology.



  - [Features](#features)
  - [Install](#install)
  - [Basic usage](#basic-usage)
  - [Supported types](#supported-types)
  - [Reading .env files](#reading-env-files)
    - [Reading a specific file](#reading-a-specific-file)
  - [Handling prefixes](#handling-prefixes)
  - [Variable expansion](#variable-expansion)
  - [Validation](#validation)
  - [Deferred validation](#deferred-validation)
  - [Serialization](#serialization)
  - [Defining custom parser behavior](#defining-custom-parser-behavior)
  - [Usage with Flask](#usage-with-flask)
  - [Usage with Django](#usage-with-django)
  - [Why...?](#why)
    - [Why envvars?](#why-envvars)
    - [Why not os.environ?](#why-not-osenviron)
    - [Why another library?](#why-another-library)
  - [License](#license)



  - Type-casting
  - Read `.env` files into `os.environ` (useful for local development)
  - Validation
  - Define custom parser behavior
  - Framework-agnostic, but integrates well with [Flask](#usage-with-flask) and [Django](#usage-with-django)



      pip install environs



  With some environment variables set...

  ```bash
  export GITHUB_USER=sloria
  export MAX_CONNECTIONS=100
  export SHIP_DATE='1984-06-25'
  export TTL=42
  export ENABLE_LOGIN=true
  export GITHUB_REPOS=webargs,konch,ped
  export GITHUB_REPO_PRIORITY="webargs=2,konch=3"
  export COORDINATES=23.3,50.0
  export LOG_LEVEL=DEBUG
  ```

  Parse them with environs...

  ```python
  from environs import Env

  env = Env()
  env.read_env()  # read .env file, if it exists

  gh_user = env("GITHUB_USER")  # => 'sloria'
  secret = env("SECRET")  # => raises error if not set


  max_connections = env.int("MAX_CONNECTIONS")  # => 100
  ship_date = env.date("SHIP_DATE")  # => datetime.date(1984, 6, 25)
  ttl = env.timedelta("TTL")  # => datetime.timedelta(0, 42)
  log_level = env.log_level("LOG_LEVEL")  # => logging.DEBUG


  enable_login = env.bool("ENABLE_LOGIN", False)  # => True
  enable_feature_x = env.bool("ENABLE_FEATURE_X", False)  # => False


  gh_repos = env.list("GITHUB_REPOS")  # => ['webargs', 'konch', 'ped']
  coords = env.list("COORDINATES", subcast=float)  # => [23.3, 50.0]


  gh_repos_priorities = env.dict(
      "GITHUB_REPO_PRIORITY", subcast_values=int
  )  # => {'webargs': 2, 'konch': 3}
  ```



  The following are all type-casting methods of `Env`:

  - `env.str`
  - `env.bool`
  - `env.int`
  - `env.float`
  - `env.decimal`
  - `env.list` (accepts optional `subcast` and `delimiter` keyword arguments)
  - `env.dict` (accepts optional `subcast_keys` and `subcast_values` keyword arguments)
  - `env.json`
  - `env.datetime`
  - `env.date`
  - `env.time`
  - `env.timedelta` (assumes value is an integer in seconds)
  - `env.url`
  - `env.uuid`
  - `env.log_level`
  - `env.path` (casts to a [`pathlib.Path`](https://docs.python.org/3/library/pathlib.html))
  - `env.enum` (casts to any given enum type specified in `type` keyword argument, accepts optional `ignore_case` keyword argument)



  ```bash

  DEBUG=true
  PORT=4567
  ```

  Call `Env.read_env` before parsing variables.

  ```python
  from environs import Env

  env = Env()

  env.read_env()

  env.bool("DEBUG")  # => True
  env.int("PORT")  # => 4567
  ```



  By default, `Env.read_env` will look for a `.env` file in current
  directory and (if no .env exists in the CWD) recurse
  upwards until a `.env` file is found.

  You can also read a specific file:

  ```python
  from environs import Env

  with open(".env.test", "w") as fobj:
      fobj.write("A=foo\n")
      fobj.write("B=123\n")

  env = Env()
  env.read_env(".env.test", recurse=False)

  assert env("A") == "foo"
  assert env.int("B") == 123
  ```



  ```python



  with env.prefixed("MYAPP_"):
      host = env("HOST", "localhost")  # => 'lolcathost'
      port = env.int("PORT", 5000)  # => 3000






  with env.prefixed("MYAPP_"):
      with env.prefixed("DB_"):
          db_host = env("HOST", "lolcathost")
          db_port = env.int("PORT", 10101)
  ```



  ```python




  from environs import Env

  env = Env(expand_vars=True)

  connection_url = env("CONNECTION_URL")  # =>'https://sloria:secret@localhost'
  year = env.int("YEAR")  # =>2020
  ```



  ```python




  from environs import Env
  from marshmallow.validate import OneOf, Length, Email

  env = Env()


  env.int("TTL", validate=lambda n: n > 0)




  env.str(
      "NODE_ENV",
      validate=OneOf(
          ["production", "development"], error="NODE_ENV must be one of: {choices}"
      ),
  )



  env.str("EMAIL", validate=[Length(min=4), Email()])

  ```



  By default, a validation error is raised immediately upon calling a parser method for an invalid environment variable.
  To defer validation and raise an exception with the combined error messages for all invalid variables, pass `eager=False` to `Env`.
  Call `env.seal()` after all variables have been parsed.

  ```python




  from environs import Env
  from marshmallow.validate import OneOf, Email, Length, Range

  env = Env(eager=False)

  TTL = env.int("TTL", validate=Range(min=0, max=100))
  NODE_ENV = env.str(
      "NODE_ENV",
      validate=OneOf(
          ["production", "development"], error="NODE_ENV must be one of: {choices}"
      ),
  )
  EMAIL = env.str("EMAIL", validate=[Length(min=4), Email()])

  env.seal()

  ```

  `env.seal()` validates all parsed variables and prevents further parsing (calling a parser method will raise an error).



  ```python

  env.dump()










  ```



  ```python



  from furl import furl


  @env.parser_for("furl")
  def furl_parser(value):
      return furl(value)


  domain = env.furl("DOMAIN")  # => furl('https://myapp.com')



  @env.parser_for("choice")
  def choice_parser(value, choices):
      if value not in choices:
          raise environs.EnvError("Invalid!")
      return value


  color = env.choice("COLOR", choices=["black"])  # => raises EnvError
  ```



  ```python


  from environs import Env

  env = Env()
  env.read_env()


  DEBUG = env.bool("FLASK_DEBUG", default=False)

  SECRET_KEY = env.str("SECRET_KEY")
  ```

  Load the configuration after you initialize your app.

  ```python


  from flask import Flask

  app = Flask(__name__)
  app.config.from_object("myapp.settings")
  ```

  For local development, use a `.env` file to override the default
  configuration.

  ```bash

  DEBUG=true
  SECRET_KEY="not so secret"
  ```

  Note: Because environs depends on [python-dotenv](https://github.com/theskumar/python-dotenv),
  the `flask` CLI will automatically read .env and .flaskenv files.



  environs includes a number of helpers for parsing connection URLs. To
  install environs with django support:

      pip install environs[django]

  Use `env.dj_db_url`, `env.dj_cache_url` and `env.dj_email_url` to parse the `DATABASE_URL`, `CACHE_URL`
  and `EMAIL_URL` environment variables, respectively.

  For more details on URL patterns, see the following projects that environs is using for converting URLs.

  - [dj-database-url](https://github.com/jacobian/dj-database-url)
  - [django-cache-url](https://github.com/epicserve/django-cache-url)
  - [dj-email-url](https://github.com/migonzalvar/dj-email-url)

  Basic example:

  ```python

  from environs import Env

  env = Env()
  env.read_env()


  DEBUG = env.bool("DEBUG", default=False)

  SECRET_KEY = env.str("SECRET_KEY")


  DATABASES = {"default": env.dj_db_url("DATABASE_URL")}


  email = env.dj_email_url("EMAIL_URL", default="smtp://")
  EMAIL_HOST = email["EMAIL_HOST"]
  EMAIL_PORT = email["EMAIL_PORT"]
  EMAIL_HOST_PASSWORD = email["EMAIL_HOST_PASSWORD"]
  EMAIL_HOST_USER = email["EMAIL_HOST_USER"]
  EMAIL_USE_TLS = email["EMAIL_USE_TLS"]


  CACHES = {"default": env.dj_cache_url("CACHE_URL")}
  ```

  For local development, use a `.env` file to override the default
  configuration.

  ```bash

  DEBUG=true
  SECRET_KEY="not so secret"
  ```

  For a more complete example, see
  [django_example.py](https://github.com/sloria/environs/blob/master/examples/django_example.py)
  in the `examples/` directory.





  See [The 12-factor App](http://12factor.net/config) section on
  [configuration](http://12factor.net/config).



  While `os.environ` is enough for simple use cases, a typical application
  will need a way to manipulate and validate raw environment variables.
  environs abstracts common tasks for handling environment variables.

  environs will help you

  - cast envvars to the correct type
  - specify required envvars
  - define default values
  - validate envvars
  - parse list and dict values
  - parse dates, datetimes, and timedeltas
  - parse expanded variables
  - serialize your configuration to JSON, YAML, etc.



  There are many great Python libraries for parsing environment variables.
  In fact, most of the credit for environs\' public API goes to the
  authors of [envparse](https://github.com/rconradharris/envparse) and
  [django-environ](https://github.com/joke2k/django-environ).

  environs aims to meet three additional goals:

  1.  Make it easy to extend parsing behavior and develop plugins.
  2.  Leverage the deserialization and validation functionality provided
      by a separate library (marshmallow).
  3.  Clean up redundant API.

  See [this GitHub
  issue](https://github.com/rconradharris/envparse/issues/12#issue-151036722)
  which details specific differences with envparse.



  MIT licensed. See the
  [LICENSE](https://github.com/sloria/environs/blob/master/LICENSE) file
  for more details.


