# packages

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

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


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

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

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

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

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

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


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

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

  Installation
  From pip:

  pip install django-rest-swagger

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


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

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

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


  h2(#philosophy). Philosophy

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


  h2(#requirements). Requirements

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


  h2(#installation). Installation

  h3(#pypi). From Pypi

  As simple as doing:

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

  h3(#source). From source

  To install django-rules from source:

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


  h2(#configuration). Configuration

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

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

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

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

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

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

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

  h2(#rules). Rules

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

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

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

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

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

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

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

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


  h2(#examples). Examples:


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

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

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

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

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

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

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

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

  <pre>
  from django_rules import utils

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







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

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

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


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

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

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

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

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

  <pre>
  from django_rules import utils

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


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

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

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


  h3. Using your rules

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

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

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

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

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

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

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

  Easy, right? :)


  h4. Details about the internal magic of django-rules

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

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


  h3. Details of using model methods in rules

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

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

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

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


  h2(#decorators). Decorators

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

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

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

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

      return HttpResponse('error')
  </pre>

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

  <pre>
  from django_rules import object_permission_required

  @object_permission_required('can_ship')
  def ship_item(request, id):
      return HttpResponse('Item successfully shipper! :)')
  </pre>

  The magic of the decorator is very cool indeed. First, it matches the rule and gets the type of model from it. Then, it gets the <code>id</code> parameter from the view's kwargs and instantiates a Model object with <code>item = model.objects.get(pk = id)</code>. Finally, it can call the <code>request.user.has_perm('can_ship', item)</code> for you and redirect to a fail page if the constraint is not fulfilled.

  Note how we have maintained the name of the model's primary key in the parameters of the view. If the parameter has a name that doesn't match the name of the primary key in the model, remember that we will have to add another optional parameter to the rule. From "the section on Rules:":#rules
  * <code>view_param_pk</code> _(optional)_: The view parameter's name to use for getting the primary key of the model. It is used in the decorated views for getting the actual instance of the model. If not set, it defaults to the name of the primary key field in the model. Note that if the name of the parameter of the view that holds the value of the object's primary key doesn't match the name of the primary key of the model, the new name must be specified in this parameter.

  For example, if we modify the parameter of the view:

  <pre>
  from django_rules import object_permission_required

  @object_permission_required('can_ship')
  def ship_item(request, my_item_code):  #--> change in the naming of the parameter in the view
      return HttpResponse('success')
  </pre>

  We would have to specify the <code>view_param_pk</code> in the rule definition:

  <pre>
  rules_list = [
      {'codename': 'can_ship', 'model': 'Item', 'view_param_pk': 'my_item_code',
       'description': 'Checks if the given user is the supplier of the item'},
  ]
  </pre>


  The <code>object_permission_required</code> decorator can receive 4 arguments:

  <pre>
  @object_permission_required('can_ship', return_403=True)
  @object_permission_required('can_ship', redirect_url='/more/foo/bar/')
  @object_permission_required('can_ship', redirect_field_name='myFooField')
  @object_permission_required('can_ship', login_url='/foo/bar/')
  </pre>

  By default:
  * <code>return_403</code> is set to False.
  * <code>redirect_url</code> is set to an empty string.
  * <code>redirect_field_name</code> is set to django.contrib.auth's REDIRECT_FIELD_NAME.
  * <code>login_url</code> is set to <code>settings.LOGIN_URL</code>.

  Thus, if the authorization constraint is not fulfilled, the decorator will default to a redirect to the login page in Django-style :)

  Also, note that a couple of the parameters have a specificity. Namely:
  * if <code>return_403</code> is set to True it will override the rest of the parameters and the decorator will return a HttpResponseForbidden.
  * if <code>redirect_url</code> is set to a URL, it will override that of <code>login_url</code>.

  Finally, it is important to note a tricky detail regarding the use of the decorator to guard the access of those methods that are not directly exposed as views mapped to external URLs. When a view method is an entry point through URLs (that is, if your view method is mapped directly to one of the <code>urls.py</code> entries), Django parses the URL and passes the parameters to the view as <code>kwargs</code>. Thus, if you want to use the <code>object_permission_required</code> decorator over an internal method (a method that is called inside one of those external views or somewhere else in your code) you must use <code>kwargs</code> when passing the parameters.

  Let's see an example:

  <pre>
  def item_shipper(request, id):
      internal_code = 'XXX-' + my_item_code
      return _ship_item(request, id=internal_code)    # instead of doing return _ship_item(request, internal_code)

  @object_permission_required('can_ship')
  def _ship_item(request, id)
      return HttpResponse('success')
  </pre>

  h2(#centralizedpermissions). Centralized Permissions

  django-rules has a central authorization dispatcher that is aimed towards a very common need in real life projects: the special, privileged groups such as administrators, user-support staff, etc., that have permissions to override certain aspects of the authorization constraints in the application. For such cases, django-rules has a way to let you bypass its authorization system for whatever reasons you have.

  To set up centralized permissions, you will need to set in your project settings the variable <code>CENTRAL_AUTHORIZATIONS</code> pointing to a module. Within that module, you will have to define a a boolean-returning function named <code>central_authorizations</code> accepting exactly two parameters:
  * <code>user_obj</code>: the user object.
  * <code>codename</code>: the codename of the rule we will be overriden. It is very useful to refine the permissions of a special user "a la ACL".
  Note that, although the naming of the parameters doesn't really matter, the order does. The first parameter will receive a user object, and the second parameter, the codename of the rule.

  This <code>central_authorizations()</code> function will be called *before* any other rule, so you can override all of them here.

  For example, in <code>settings.py</code> you will add:

  <pre>
  CENTRAL_AUTHORIZATIONS = 'myProjectFoo.utils'
  </pre>

  And then, within myProjectFoo, in <code>utils.py</code>, you will implement the <code>central_authorizations()</code> function with the overrides for the special users.

  Imagine you want to give some special access to user support staff that will be able to access some private fields in the profile (for example, email and age) that generally are hidden to regular users of the application. They are user support, so they should not be able to override certain things in the application. Yet, you also want your über-admins (generally the developers) to be able to access anything within the application so that they can code and test quickly while developing.

  In such case, you can write the following <code>central_authorizations()</code> function:

  <pre>
  def central_authorizations(user_obj, codename):
      """
      This function will be called *before* any other rule,
      so you can override all of the permissions here.
      """
      isAuthorized = False

      if user_obj.get_profile().isUberAdmin():
          isAuthorized = True
      elif user_obj.get_profile().isUserSupport() and codename in ['can_see_full_profile', 'can_delete_item']:
          isAuthorized = True

      return isAuthorized
  </pre>

  As you can imagine, everything that is checked in <code>central_authorizations</code> is global to the *whole* project.


  h2. Status and testing

  django-rules is meant to be a security application. Thus, it has been thoroughly tested. It comes with a battery of tests that tries to cover all of the available funcionality. However, if you come across a bug or an irregular situation, feel free to report it through the "Github bug tracker":https://github.com/maraujop/django-rules/issues.

  Finally, the application comes geared with many different exceptions that will make sure rules are created properly. They are also aimed to keep the security of your application away from negligence. Manage the exceptions wisely and you will be a happy and secure coder, as security is kept away from possible neglicence. You should manage them carefuly.


  h3. Testing django-rules

  To run tests, get into tests directory and execute:

  <pre>
  ./runtests.py
  </pre>

  It should always say OK. If not, there is a broken test that I hope you will be reporting soon :)


  h2. Need more examples?

  I have done my best trying to explain the concept behind django-rules but, if you would rather look at more code examples, I am sure you will find the "code in the tests":https://github.com/maraujop/django-rules/blob/master/django_rules/tests/test_core.py quite useful :)


  h2. More Documentation

  In case you want to know where all this "per-object authentication backend in Django" came to exist, you should at least read the following links:
  * A great article about "per-object permission backends in Django":http://djangoadvent.com/1.2/object-permissions/ by Florian Apolloner
  * Also, check the explanation of the changes introduced when fixing the "django ticket #11010":http://code.djangoproject.com/ticket/11010

  Finally, my most sincere appreciation goes to everybody that contributes to the wonderful Django development framework and also to the rest of developers and committers that build django-rules with their help. Respect! :)


pkgId: f114362e3215620b0e9faeff478e11d6239e5a6be548a78f077b30cb897f3a2d
name: python-django-sass-processor
arch: src
version: 1.2.2
epoch: 0
release: 1
summary: SASS processor to compile SCSS files into *.css, while rendering, or offline.
url: https://github.com/jrief/django-sass-processor
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1884bd9f-95fc-439e-86a4-e9519fac430a
location_href: 00013069-python-django-sass-processor/python-django-sass-processor-1.2.2-1.src.rpm
checksum_type: sha256
description:
  Annoyed having to run a Compass, Grunt or Gulp daemon while developing Django projects?

  Well, then this app is for you! Compile SASS/SCSS files on the fly without having to manage
  third party services nor special IDE plugins.

  [![Build Status](https://github.com/jrief/django-sass-processor/actions/workflows/tests.yml/badge.svg)](https://github.com/jrief/django-sass-processor/actions)
  [![PyPI](https://img.shields.io/pypi/pyversions/django-sass-processor.svg)]()
  [![PyPI version](https://img.shields.io/pypi/v/django-sass-processor.svg)](https://pypi.python.org/pypi/django-sass-processor)
  [![PyPI](https://img.shields.io/pypi/l/django-sass-processor.svg)]()
  [![Downloads](https://img.shields.io/pypi/dm/django-sass-processor.svg)](https://pypi.python.org/pypi/django-sass-processor)
  [![Twitter Follow](https://img.shields.io/twitter/follow/shields_io.svg?style=social&label=Follow&maxAge=2592000)](https://twitter.com/jacobrief)




  * Refer SASS/SCSS files directly from your sources, instead of referring a compiled CSS file,
  having to rely on another utility which creates them from SASS/SCSS files, hidden in
  your source tree.
  * Use Django's `settings.py` for the configuration of paths, box sizes etc., instead of having another
  SCSS specific file (typically `_variables.scss`), to hold these.
  * Extend your SASS functions by calling Python functions directly out of your Django project.
  * View SCSS errors directly in the debug console of your Django's development server.

  **django-sass-processor** converts `*.scss` or `*.sass` files into `*.css` while rendering
  templates. For performance reasons this is done only once, since the preprocessor keeps track on
  the timestamps and only recompiles, if any of the imported SASS/SCSS files is younger than the
  corresponding generated CSS file.



  This Django app provides a templatetag `{% sass_src 'path/to/file.scss' %}`, which can be used
  instead of the built-in templatetag `static`. This templatetag also works inside Jinja2 templates.

  If SASS/SCSS files shall be referenced through the `Media` class, or `media` property, the SASS
  processor can be used directly.

  Additionally, **django-sass-processor** is shipped with a management command, which can convert
  the content of all occurrences inside the templatetag `sass_src` as an offline operation. Hence
  the **libsass** compiler is not required in a production environment.

  During development, a [sourcemap](https://developer.chrome.com/devtools/docs/css-preprocessors) is
  generated along side with the compiled `*.css` file. This allows to debug style sheet errors much
  easier.

  With this tool, you can safely remove your Ruby installations "Compass" and "SASS" from your Django
  projects. You neither need any directory "watching" daemons based on node.js.



  On GitHub:

  https://github.com/jrief/django-sass-processor

  Please use the issue tracker to report bugs or propose new features.



  ```
  pip install libsass django-compressor django-sass-processor
  ```

  `django-compressor` is required only for offline compilation, when using the command
  `manage.py compilescss`.

  `libsass` is not required on the production environment, if SASS/SCSS files have been precompiled
  and deployed using offline compilation.



  In `settings.py` add to:

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

  **django-sass-processor** is shipped with a special finder, to locate the generated `*.css` files
  in the directory referred by `SASS_PROCESSOR_ROOT` (or, if unset `STATIC_ROOT`). Just add it to
  your `settings.py`. If there is no `STATICFILES_FINDERS` in your `settings.py` don't forget
  to include the **Django** [default finders](https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-STATICFILES_FINDERS).

  ```python
  STATICFILES_FINDERS = [
      'django.contrib.staticfiles.finders.FileSystemFinder',
      'django.contrib.staticfiles.finders.AppDirectoriesFinder',
      'sass_processor.finders.CssFinder',
      ...
  ]
  ```

  Optionally, add a list of additional search paths, the SASS compiler may examine when using the
  `@import "...";` statement in SASS/SCSS files:

  ```python
  import os

  SASS_PROCESSOR_INCLUDE_DIRS = [
      os.path.join(PROJECT_PATH, 'extra-styles/scss'),
      os.path.join(PROJECT_PATH, 'node_modules'),
  ]
  ```

  Additionally, **django-sass-processor** will traverse all installed Django apps (`INSTALLED_APPS`)
  and look into their static folders. If any of them contain a file matching the regular expression
  pattern `^_.+\.(scss|sass)$` (read: filename starts with an underscore and is of type `scss` or
  `sass`), then that app specific static folder is added to the **libsass** include dirs. This
  feature can be disabled in your settings with:

  ```python
  SASS_PROCESSOR_AUTO_INCLUDE = False
  ```

  If inside of your SASS/SCSS files, you also want to import (using `@import "path/to/scssfile";`)
  files which do not start with an underscore, then you can configure another Regex pattern in your
  settings, for instance:

  ```python
  SASS_PROCESSOR_INCLUDE_FILE_PATTERN = r'^.+\.scss$'
  ```

  will look for all files of type `scss`. Remember that SASS/SCSS files which start with an
  underscore, are intended to be imported by other SASS/SCSS files, while files starting with a
  letter or number are intended to be included by the HTML tag
  `<link href="{% sass_src 'path/to/file.scss' %}" ...>`.

  During development, or when `SASS_PROCESSOR_ENABLED = True`, the compiled file is placed into the
  folder referenced by `SASS_PROCESSOR_ROOT` (if unset, this setting defaults to `STATIC_ROOT`).
  Having a location outside of the working directory prevents to pollute your local `static/css/...`
  directories with auto-generated files. Therefore assure, that this directory is writable by the
  Django runserver.




  Integer `SASS_PRECISION` sets floating point precision for output css. libsass'
  default is `5`. Note: **bootstrap-sass** requires `8`, otherwise various
  layout problems _will_ occur.

  ```python
  SASS_PRECISION = 8
  ```

  `SASS_OUTPUT_STYLE` sets coding style of the compiled result, one of `compact`,
  `compressed`, `expanded`, or `nested`. Default is `nested` for `DEBUG`
  and `compressed` in production.

  Note: **libsass-python** 0.8.3 has [problem encoding result while saving on
  Windows](https://github.com/dahlia/libsass-python/pull/82), the issue is already
  fixed and will be included in future `pip` package release, in the meanwhile
  avoid `compressed` output style.

  ```python
  SASS_OUTPUT_STYLE = 'compact'
  ```



  `sass_processor.jinja2.ext.SassSrc` is a Jinja2 extension. Add it to your Jinja2 environment to enable the tag `sass_src`, there is no need for a `load` tag. Example of how to add your Jinja2 environment to Django:

  In `settings.py`:

  ```python
  TEMPLATES = [{
      'BACKEND': 'django.template.backends.jinja2.Jinja2',
      'DIRS': [],
      'APP_DIRS': True,
      'OPTIONS': {
          'environment': 'yourapp.jinja2.environment'
      },
      ...
  }]
  ```

  Make sure to add the default template backend, if you're still using Django templates elsewhere.
  This is covered in the [Upgrading templates documentation](https://docs.djangoproject.com/en/stable/ref/templates/upgrading/).

  In `yourapp/jinja2.py`:

  ```python

  from __future__ import absolute_import

  from jinja2 import Environment


  def environment(**kwargs):
      extensions = [] if 'extensions' not in kwargs else kwargs['extensions']
      extensions.append('sass_processor.jinja2.ext.SassSrc')
      kwargs['extensions'] = extensions

      return Environment(**kwargs)
  ```

  If you want to make use of the `compilescss` command, then you will also have to add the following to your settings:

  ```python
  from yourapp.jinja2 import environment

  COMPRESS_JINJA2_GET_ENVIRONMENT = environment
  ```






  ```django
  {% load sass_tags %}

  <link href="{% sass_src 'myapp/css/mystyle.scss' %}" rel="stylesheet" type="text/css" />
  ```

  The above template code will be rendered as HTML

  ```html
  <link href="/static/myapp/css/mystyle.css" rel="stylesheet" type="text/css" />
  ```

  You can safely use this templatetag inside a [Sekizai](https://django-sekizai.readthedocs.io/)'s
  `{% addtoblock "css" %}` statement.



  In Python code, you can access the API of the SASS processor directly. This for instance is useful
  in Django's admin or form framework.

  ```python
  from sass_processor.processor import sass_processor

  class SomeAdminOrFormClass(...):
      ...
      class Media:
          css = {
              'all': [sass_processor('myapp/css/mystyle.scss')],
          }
  ```



  Writing SCSS shall be fast and easy and you should not have to care, whether to add vendor specific
  prefixes to your CSS directives. Unfortunately there is no pure Python package to solve this, but
  with a few node modules, we can add this to our process chain.

  As superuser install

  ```shell
  npm install -g npx
  ```

  and inside your project root, install

  ```shell
  npm install postcss-cli autoprefixer
  ```

  Check that the path of `node_modules` corresponds to its entry in the settings directive
  `STATICFILES_DIRS` (see below).

  In case `npx` can not be found in your system path, use the settings directive
  `NODE_NPX_PATH = /path/to/npx` to point to that executable.

  If everything is setup correctly, **django-sass-processor** adds all required vendor prefixes to
  the compiled CSS files. For further information, refer to the
  [Autoprefixer](https://github.com/postcss/autoprefixer) package.

  To disable autoprefixing, set `NODE_NPX_PATH = None`.

  **Important note**: If `npx` is installed, but `postcss` and/or `autoprefixer` are missing
  in the local `node_modules`, setting `NODE_NPX_PATH` to `None` is manadatory, otherwise
  **django-sass-processor** does not know how to postprocess the generated CSS files.



  If you want to precompile all occurrences of your SASS/SCSS files for the whole project, on the
  command line invoke:

  ```shell
  ./manage.py compilescss
  ```

  This is useful for preparing production environments, where SASS/SCSS files can't be compiled on
  the fly.

  To simplify the deployment, the compiled `*.css` files are stored side-by-side with their
  corresponding SASS/SCSS files. After compiling the files run

  ```shell
  ./manage.py collectstatic
  ```

  as you would in a normal deployment.

  In case you don't want to expose the SASS/SCSS files in a production environment,
  deploy with:

  ```shell
  ./manage.py collectstatic --ignore=*.scss
  ```

  To get rid of the compiled `*.css` files in your local static directories, simply reverse the
  above command:

  ```shell
  ./manage.py compilescss --delete-files
  ```

  This will remove all occurrences of previously generated `*.css` files.

  Or you may compile results to the `SASS_PROCESSOR_ROOT` directory directy (if not specified - to
  `STATIC_ROOT`):

  ```shell
  ./manage.py compilescss --use-storage
  ```

  Combine with `--delete-files` switch to purge results from there.

  If you use an alternative templating engine set its name in `--engine` argument. Currently
  `django` and `jinja2` are supported, see
  [django-compressor documentation](http://django-compressor.readthedocs.org/en/latest/) on how to
  set up `COMPRESS_JINJA2_GET_ENVIRONMENT` to configure jinja2 engine support.

  During offline compilation **django-sass-processor** parses all Python files and looks for
  invocations of `sass_processor('path/to/sassfile.scss')`. Therefore the string specifying
  the filename must be hard coded and shall not be concatenated or being somehow generated.



  By default, **django-sass-processor** will locate SASS/SCSS files from .html templates,
  but you can extend or override this behavior in your settings with:

  ```python
  SASS_TEMPLATE_EXTS = ['.html','.jade']
  ```



  In SASS, a nasty problem is to set the correct include paths for icons and fonts. Normally this is
  done through a `_variables.scss` file, but this inhibits a configuration through your projects
  `settings.py`.

  To avoid the need for duplicate configuration settings, **django-sass-processor** offers a SASS
  function to fetch any arbitrary configuration directive from the project's `settings.py`. This
  is specially handy to set the include path of your Glyphicons font directory. Assume, Bootstrap-SASS
  has been installed using:

  ```shell
  npm install bootstrap-sass
  ```

  then locate the directory named `node_modules` and add it to your settings, so that your fonts are
  accessible through the Django's `django.contrib.staticfiles.finders.FileSystemFinder`:

  ```python
  STATICFILES_DIRS = [
      ...
      ('node_modules', '/path/to/your/project/node_modules/'),
      ...
  ]

  NODE_MODULES_URL = STATIC_URL + 'node_modules/'
  ```

  With the SASS function `get-setting`, it is possible to override any SASS variable with a value
  configured in the project's `settings.py`. For the Glyphicons font search path, add this to your
  `_variables.scss`:

  ```scss
  $icon-font-path: unquote(get-setting(NODE_MODULES_URL) + "bootstrap-sass/assets/fonts/bootstrap/");
  ```

  and `@import "variables";` whenever you need Glyphicons. You then can safely remove any font
  references, such as `<link href="/path/to/your/fonts/bootstrap/glyphicons-whatever.ttf" ...>`
  from you HTML templates.




  It is even possible to call Python functions from inside any module. Do this by adding
  `SASS_PROCESSOR_CUSTOM_FUNCTIONS` to the project's `settings.py`. This shall contain a mapping
  of SASS function names pointing to a Python function name.

  Example:

  ```python
  SASS_PROCESSOR_CUSTOM_FUNCTIONS = {
      'get-color': 'myproject.utils.get_color',
  }
  ```

  This allows to invoke Python functions out of any `*.scss` file.

  ```scss
  $color: get-color(250, 10, 120);
  ```

  Here we pass the parameters '250, 10, 120' into the function `def get_color(red, green, blue)`
  in Python module `myproject.utils`. Note that this function receives the values as `sass.Number`,
  hence extract values using `red.value`, etc.

  If one of these customoized functions returns a value, which is not a string, then convert it
  either to a Python string or to a value of type `sass.SassNumber`. For other types, refer to their
  documentation.

  Such customized functions must accept parameters explicilty, otherwise `sass_processor` does not
  know how to map them. Variable argument lists therefore can not be used.




  Whenever **django-sass-processor** runs in debug mode and fails to compile a SASS/SCSS file, it
  raises a `sass.CompileError` exception. This shows the location of the error directly on the
  Django debug console and is very useful during development.

  This behaviour can be overridden using the settings variable `SASS_PROCESSOR_FAIL_SILENTLY`.
  If it is set to `True`, instead of raising that exception, the compilation error message is send
  to the Django logger.




  Under the hood, SASS processor will use any storage configured in your settings as `STATICFILES_STORAGE`.
  This means you can use anything you normally use for serving static files, e.g. S3.

  A custom Storage class can be used if your deployment needs to serve generated CSS files from elsewhere,
  e.g. when your static files storage is not writable at runtime and you nede to re-compile CSS
  in production. To use a custom storage, configure it in `SASS_PROCESSOR_STORAGE`. You can also
  configure a dictionary with options that will be passed to the storage class as keyword arguments
  in `SASS_PROCESSOR_STORAGE_OPTIONS` (e.g. if you want to use `FileSystemStorage`, but with
  a different `location` or `base_url`:

  ```python
  SASS_PROCESSOR_STORAGE = 'django.core.files.storage.FileSystemStorage'
  SASS_PROCESSOR_STORAGE_OPTIONS = {
      'location': '/srv/media/generated',
      'base_url': 'https://media.myapp.example.com/generated'
  }
  ```




  Using the S3 storage backend from [django-storages](https://django-storages.readthedocs.io/en/latest/)
  with its regular configuration (if you do not otherwise use it for service static files):

  ```python
  SASS_PROCESSOR_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
  ```




  If you are deploying to [Heroku](https://www.heroku.com/), use the
  [heroku-buildpack-django-sass](https://elements.heroku.com/buildpacks/drpancake/heroku-buildpack-django-sass)
  buildpack to automatically compile scss for you.




  To run the tests locally, clone the repository, and, in your local copy, create a new virtualenv.
  these commands:

  ```shell
  python -m pip install --upgrade pip
  pip install Django
  pip install -r tests/requirements.txt
  python -m pytest tests
  ```




  Brian wrote a nice artice on
  [how to easily use SASS/SCSS with Django](https://engineertodeveloper.com/how-to-easily-use-sass-scss-with-django/).


pkgId: f41f43f40000d0f2454c67441cb79febd1bb859345ace667167bff1a383fb51e
name: python-django-sendgrid-v5
arch: src
version: 1.2.2
epoch: 0
release: 1
summary: An implementation of Django's EmailBackend compatible with sendgrid-python v5+
url: https://github.com/sklarsa/django-sendgrid-v5
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-049f24b1-d0a9-4a97-9da3-811ef0fbc635
location_href: 00012469-python-django-sendgrid-v5/python-django-sendgrid-v5-1.2.2-1.src.rpm
checksum_type: sha256
description:
  [![Latest Release](https://img.shields.io/pypi/v/django-sendgrid-v5.svg)](https://pypi.python.org/pypi/django-sendgrid-v5/)

  This package implements an email backend for Django that relies on sendgrid's REST API for message delivery.

  It is under active development, and pull requests are more than welcome\!

  To use the backend, simply install the package (using pip), set the `EMAIL_BACKEND` setting in Django, and add a `SENDGRID_API_KEY` key (set to the appropriate value) to your Django settings.



  1. `pip install django-sendgrid-v5`
  2. In your project's settings.py script:
      1. Set `EMAIL_BACKEND = "sendgrid_backend.SendgridBackend"`
      2. Set the SENDGRID\_API\_KEY in settings.py to your api key that was provided to you by sendgrid. `SENDGRID_API_KEY = os.environ["SENDGRID_API_KEY"]`



  1. To toggle sandbox mode (when django is running in DEBUG mode), set `SENDGRID_SANDBOX_MODE_IN_DEBUG = True/False`.
      1. To err on the side of caution, this defaults to True, so emails sent in DEBUG mode will not be delivered, unless this setting is explicitly set to False.
  2. `SENDGRID_ECHO_TO_STDOUT` will echo to stdout or any other file-like
      object that is passed to the backend via the `stream` kwarg.
  3. `SENDGRID_TRACK_EMAIL_OPENS` - defaults to true and tracks email open events via the Sendgrid service. These events are logged in the Statistics UI, Email Activity interface, and are reported by the Event Webhook.
  4. `SENDGRID_TRACK_CLICKS_HTML` - defaults to true and, if enabled in your Sendgrid account, will tracks click events on links found in the HTML message sent.
  5. `SENDGRID_TRACK_CLICKS_PLAIN` - defaults to true and, if enabled in your Sendgrid account, will tracks click events on links found in the plain text message sent.





  ```python
  from django.core.mail import send_mail

  send_mail(
      'Subject here',
      'Here is the message.',
      'from@example.com',
      ['to@example.com'],
      fail_silently=False,
  )
  ```



  First, create a [dynamic template](https://mc.sendgrid.com/dynamic-templates) and copy the ID.

  ```python
  from django.core.mail import EmailMessage

  msg = EmailMessage(
    from_email='to@example.com',
    to=['to@example.com'],
  )
  msg.template_id = "your-dynamic-template-id"
  msg.dynamic_template_data = {
    "title": foo
  }
  msg.send(fail_silently=False)
  ```



  ```python
  from django.core.mail import EmailMessage

  msg = EmailMessage(
    from_email='to@example.com',
    to=['to@example.com'],
    cc=['cc@example.com'],
    bcc=['bcc@example.com'],
  )



  msg.custom_args = {'arg1': 'value1', 'arg2': 'value2'}


  msg.reply_to = 'reply-to@example.com'



  msg.send_at = 1600188812



  msg.template_id = "your-dynamic-template-id"
  msg.dynamic_template_data = {  # Sendgrid v6+ only
    "title": foo
  }
  msg.substitutions = {
    "title": bar
  }



  msg.asm = {'group_id': 123, 'groups_to_display': ['group1', 'group2']}



  msg.categories = ['category1', 'category2']



  msg.ip_pool_name = 'my-ip-pool'


  msg.send(fail_silently=False)
  ```



  **How to change a Sender's Name ?**


  `from_email="John Smith <john.smith@example.org>"`
  You can just include the name in the from_email field of the _```EmailMessage```_ class

  ```
  msg = EmailMessage(
    from_email='Sender Name <from@example.com>',
    to=['to@example.com'],
  )
  ```

  **How to make mails to multiple users private (hide all the email addresses to which the mail is sent) to each person (personalization) ?**


  Setting the `make_private` attribute to `True` will help us achieve it
  ```
  msg = EmailMessage(
    from_email='Sender Name <from@example.com>',
    to=['to@example.com','abc@example.com','xyz@example.com'],
  )
  msg.make_private = True
  ```



  - Marcelo Canina [(@marcanuy)](https://github.com/marcanuy) wrote a great article demonstrating how to integrate `django-sendgrid-v5` into your Django application on his site: [https://simpleit.rocks/python/django/adding-email-to-django-the-easiest-way/](https://simpleit.rocks/python/django/adding-email-to-django-the-easiest-way/)
  - RX-36 [(@DevWoody856)](https://github.com/DevWoody856) demonstrates how to use `django-sendgrid-v5` to make a contact form for your web application: https://rx-36.life/post/create-a-contact-form-using-sendgrid-in-django/




  [![Stargazers over time](https://starchart.cc/sklarsa/django-sendgrid-v5.svg)](https://starchart.cc/sklarsa/django-sendgrid-v5)


pkgId: 47818faa39256885cb27650483f11481267a555d436324b541f6764f2143f356
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-975f269e-1060-428d-b92b-617acb74420f
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: bab9a309df796fe838a57e191340909a7b2c3b4b805fab9ee3a1bcf4bb0cabe1
name: python-django-settings-export
arch: src
version: 1.2.1
epoch: 0
release: 1
summary: This Django app allows you to export certain settings to your templates.
url: https://github.com/jkbrzt/django-settings-export
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5dd1c10e-e40e-4ad6-b95e-44a8e58b97ef
location_href: 00012415-python-django-settings-export/python-django-settings-export-1.2.1-1.src.rpm
checksum_type: sha256
description:
      $ pip install django-settings-export
  Add ``'django_settings_export.settings_export'`` to
  template context processor list in your ``settings.py``:
  **Django 1.8 and newer:**
      TEMPLATES = [
          {
              
              'OPTIONS': {
                  'context_processors': [
                      
                      'django_settings_export.settings_export',
                  ],
              },
          },
      ]
  **Django older than 1.8:**
      TEMPLATE_CONTEXT_PROCESSORS = [
          
          'django_settings_export.settings_export',
      ]


pkgId: 94ba1b5305cad2279d45d6a9e5df633e123657f119f69e9494b784895b566550
name: python-django-silk
arch: src
version: 5.0.3
epoch: 0
release: 1
summary: Silky smooth profiling for the Django Framework
url: https://github.com/jazzband/django-silk
rpm_license: MIT License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d4518a91-114b-405a-9182-7b6878a8c49d
location_href: 00010690-python-django-silk/python-django-silk-5.0.3-1.src.rpm
checksum_type: sha256
description:
  [![GitHub Actions](https://github.com/jazzband/django-silk/workflows/Test/badge.svg)](https://github.com/jazzband/django-silk/actions)
  [![GitHub Actions](https://codecov.io/gh/jazzband/django-silk/branch/master/graph/badge.svg)](https://codecov.io/gh/jazzband/django-silk)
  [![PyPI Download](https://img.shields.io/pypi/v/django-silk.svg)](https://pypi.python.org/pypi/django-silk)
  [![PyPI Python Versions](https://img.shields.io/pypi/pyversions/django-silk.svg)](https://pypi.python.org/pypi/django-silk)
  [![Supported Django versions](https://img.shields.io/pypi/djversions/django-silk.svg)](https://pypi.python.org/pypi/django-silk)
  [![Jazzband](https://jazzband.co/static/img/badge.svg)](https://jazzband.co/)

  Silk is a live profiling and inspection tool for the Django framework. Silk intercepts and stores HTTP requests and database queries before presenting them in a user interface for further inspection:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/1.png" width="720px"/>



  * [Requirements](#requirements)
  * [Installation](#installation)
  * [Features](#features)
  * [Configuration](#configuration)
    * [Authentication/Authorisation](#authenticationauthorisation)
    * [Request/Response bodies](#requestresponse-bodies)
    * [Meta-Profiling](#meta-profiling)
    * [Recording a fraction of requests](#recording-a-fraction-of-requests)
    * [Limiting request/response data](#limiting-requestresponse-data)
    * [Clearing logged data](#clearing-logged-data)
  * [Contributing](#contributing)
    * [Development Environment](#development-environment)



  Silk has been tested with:

  * Django: 3.2, 4.0, 4.1
  * Python: 3.7, 3.8, 3.9, 3.10, 3.11



  Via pip into a `virtualenv`:

  ```bash
  pip install django-silk
  ```

  In `settings.py` add the following:

  ```python
  MIDDLEWARE = [
      ...
      'silk.middleware.SilkyMiddleware',
      ...
  ]

  INSTALLED_APPS = (
      ...
      'silk'
  )
  ```

  **Note:** The middleware placement is sensitive. If the middleware before `silk.middleware.SilkyMiddleware` returns from `process_request` then `SilkyMiddleware` will never get the chance to execute. Therefore you must ensure that any middleware placed before never returns anything from `process_request`. See the [django docs](https://docs.djangoproject.com/en/dev/topics/http/middleware/#process-request) for more information on this.

  **Note:** If you are using `django.middleware.gzip.GZipMiddleware`, place that **before** `silk.middleware.SilkyMiddleware`, otherwise you will get an encoding error.

  If you want to use custom middleware, for example you developed the subclass of `silk.middleware.SilkyMiddleware`, so you can use this combination of settings:

  ```python

  SILKY_MIDDLEWARE_CLASS = 'path.to.your.middleware.MyCustomSilkyMiddleware'


  MIDDLEWARE = [
      ...
      SILKY_MIDDLEWARE_CLASS,
      ...
  ]
  ```

  To enable access to the user interface add the following to your `urls.py`:

  ```python
  urlpatterns += [path('silk/', include('silk.urls', namespace='silk'))]
  ```

  before running migrate:

  ```bash
  python manage.py migrate

  python manage.py collectstatic
  ```


  Silk will automatically begin interception of requests and you can proceed to add profiling
  if required. The UI can be reached at `/silk/`



  Via [github tags](https://github.com/jazzband/django-silk/releases):

  ```bash
  pip install https://github.com/jazzband/silk/archive/<version>.tar.gz
  ```

  You can install from master using the following, but please be aware that the version in master
  may not be working for all versions specified in [requirements](#requirements)

  ```bash
  pip install -e git+https://github.com/jazzband/django-silk.git#egg=django-silk
  ```



  Silk primarily consists of:

  * Middleware for intercepting Requests/Responses
  * A wrapper around SQL execution for profiling of database queries
  * A context manager/decorator for profiling blocks of code and functions either manually or dynamically.
  * A user interface for inspection and visualisation of the above.



  The Silk middleware intercepts and stores requests and responses in the configured database.
  These requests can then be filtered and inspecting using Silk's UI through the request overview:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/1.png" width="720px"/>

  It records things like:

  * Time taken
  * Num. queries
  * Time spent on queries
  * Request/Response headers
  * Request/Response bodies

  and so on.

  Further details on each request are also available by clicking the relevant request:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/2.png" width="720px"/>



  Silk also intercepts SQL queries that are generated by each request. We can get a summary on things like
  the tables involved, number of joins and execution time (the table can be sorted by clicking on a column header):

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/3.png" width="720px"/>

  Before diving into the stack trace to figure out where this request is coming from:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/5.png" width="720px"/>



  Turn on the SILKY_PYTHON_PROFILER setting to use Python's built-in cProfile profiler. Each request will be separately profiled and the profiler's output will be available on the request's Profiling page in the Silk UI.

  ```python
  SILKY_PYTHON_PROFILER = True
  ```

  If you would like to also generate a binary `.prof` file set the following:

  ```python
  SILKY_PYTHON_PROFILER_BINARY = True
  ```

  When enabled, a graph visualisation generated using [gprof2dot](https://github.com/jrfonseca/gprof2dot) and [viz.js](https://github.com/almende/vis) is shown in the profile detail page:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/10.png" width="720px"/>


  A custom storage class can be used for the saved generated binary `.prof` files:

  ```python
  SILKY_STORAGE_CLASS = 'path.to.StorageClass'
  ```

  The default storage class is `silk.storage.ProfilerResultStorage`, and when using that you can specify a path of your choosing. You must ensure the specified directory exists.

  ```python

  SILKY_PYTHON_PROFILER_RESULT_PATH = '/path/to/profiles/'
  ```

  A download button will become available with a binary `.prof` file for every request. This file can be used for further analysis using [snakeviz](https://github.com/jiffyclub/snakeviz) or other cProfile tools


  Silk can also be used to profile specific blocks of code/functions. It provides a decorator and a context
  manager for this purpose.

  For example:

  ```python
  from silk.profiling.profiler import silk_profile


  @silk_profile(name='View Blog Post')
  def post(request, post_id):
      p = Post.objects.get(pk=post_id)
      return render(request, 'post.html', {
          'post': p
      })
  ```

  Whenever a blog post is viewed we get an entry within the Silk UI:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/7.png" width="720px"/>

  Silk profiling not only provides execution time, but also collects SQL queries executed within the block in the same fashion as with requests:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/8.png" width="720px"/>



  The silk decorator can be applied to both functions and methods

  ```python
  from silk.profiling.profiler import silk_profile



  @silk_profile(name='View Blog Post')
  def post(request, post_id):
      p = Post.objects.get(pk=post_id)
      return render(request, 'post.html', {
          'post': p
      })



  class MyView(View):
      @silk_profile(name='View Blog Post')
      def get(self, request):
          p = Post.objects.get(pk=post_id)
          return render(request, 'post.html', {
              'post': p
          })
  ```



  Using a context manager means we can add additional context to the name which can be useful for
  narrowing down slowness to particular database records.

  ```python
  def post(request, post_id):
      with silk_profile(name='View Blog Post #%d' % self.pk):
          p = Post.objects.get(pk=post_id)
          return render(request, 'post.html', {
              'post': p
          })
  ```



  One of Silk's more interesting features is dynamic profiling. If for example we wanted to profile a function in a dependency to which we only have read-only access (e.g. system python libraries owned by root) we can add the following to `settings.py` to apply a decorator at runtime:

  ```python
  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'MyClass.bar'
  }]
  ```

  which is roughly equivalent to:

  ```python
  class MyClass:
      @silk_profile()
      def bar(self):
          pass
  ```

  The below summarizes the possibilities:

  ```python

  """
  Dynamic function decorator
  """

  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'foo'
  }]


  @silk_profile()
  def foo():
      pass

  """
  Dynamic method decorator
  """

  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'MyClass.bar'
  }]


  class MyClass:

      @silk_profile()
      def bar(self):
          pass

  """
  Dynamic code block profiling
  """

  SILKY_DYNAMIC_PROFILING = [{
      'module': 'path.to.module',
      'function': 'foo',
      
      'start_line': 1,
      'end_line': 2,
      'name': 'Slow Foo'
  }]


  def foo():
      with silk_profile(name='Slow Foo'):
          print (1)
          print (2)
      print(3)
      print(4)
  ```

  Note that dynamic profiling behaves in a similar fashion to that of the python mock framework in that
  we modify the function in-place e.g:

  ```python
  """ my.module """
  from another.module import foo


  foo()

  ```

  ,we would profile `foo` by dynamically decorating `my.module.foo` as opposed to `another.module.foo`:

  ```python
  SILKY_DYNAMIC_PROFILING = [{
      'module': 'my.module',
      'function': 'foo'
  }]
  ```

  If we were to apply the dynamic profile to the functions source module `another.module.foo` **after**
  it has already been imported, no profiling would be triggered.




  Sometimes you may want to dynamically control when the profiler runs. You can write your own logic for when to enable the profiler. To do this add the following to your `settings.py`:

  This setting is mutually exclusive with SILKY_PYTHON_PROFILER and will be used over it if present. It will work with SILKY_DYNAMIC_PROFILING.

  ```python
  def my_custom_logic(request):
      return 'profile_requests' in request.session

  SILKY_PYTHON_PROFILER_FUNC = my_custom_logic # profile only session has recording enabled.
  ```

  You can also use a `lambda`.

  ```python

  SILKY_PYTHON_PROFILER_FUNC = lambda request: 'profile_requests' in request.session
  ```



  Silk currently generates two bits of code per request:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/9.png" width="720px"/>

  Both are intended for use in replaying the request. The curl command can be used to replay via command-line and the python code can be used within a Django unit test or simply as a standalone script.





  By default anybody can access the Silk user interface by heading to `/silk/`. To enable your Django
  auth backend place the following in `settings.py`:

  ```python
  SILKY_AUTHENTICATION = True  # User must login
  SILKY_AUTHORISATION = True  # User must have permissions
  ```

  If `SILKY_AUTHORISATION` is `True`, by default Silk will only authorise users with `is_staff` attribute set to `True`.

  You can customise this using the following in `settings.py`:

  ```python
  def my_custom_perms(user):
      return user.is_allowed_to_use_silk

  SILKY_PERMISSIONS = my_custom_perms
  ```

  You can also use a `lambda`.

  ```python
  SILKY_PERMISSIONS = lambda user: user.is_superuser
  ```



  By default, Silk will save down the request and response bodies for each request for future viewing
  no matter how large. If Silk is used in production under heavy volume with large bodies this can have
  a huge impact on space/time performance. This behaviour can be configured with the following options:

  ```python
  SILKY_MAX_REQUEST_BODY_SIZE = -1  # Silk takes anything <0 as no limit
  SILKY_MAX_RESPONSE_BODY_SIZE = 1024  # If response body>1024 bytes, ignore
  ```



  Sometimes it is useful to be able to see what effect Silk is having on the request/response time. To do this add
  the following to your `settings.py`:

  ```python
  SILKY_META = True
  ```

  Silk will then record how long it takes to save everything down to the database at the end of each
  request:

  <img src="https://raw.githubusercontent.com/jazzband/django-silk/master/screenshots/meta.png"/>

  Note that in the above screenshot, this means that the request took 29ms (22ms from Django and 7ms from Silk)



  On high-load sites it may be helpful to only record a fraction of the requests that are made. To do this add the following to your `settings.py`:

  Note: This setting is mutually exclusive with SILKY_INTERCEPT_FUNC.

  ```python
  SILKY_INTERCEPT_PERCENT = 50 # log only 50% of requests
  ```



  On high-load sites it may also be helpful to write your own logic for when to intercept requests. To do this add the following to your `settings.py`:

  Note: This setting is mutually exclusive with SILKY_INTERCEPT_PERCENT.

  ```python
  def my_custom_logic(request):
      return 'record_requests' in request.session

  SILKY_INTERCEPT_FUNC = my_custom_logic # log only session has recording enabled.
  ```

  You can also use a `lambda`.

  ```python

  SILKY_INTERCEPT_FUNC = lambda request: 'record_requests' in request.session
  ```



  To make sure silky garbage collects old request/response data, a config var can be set to limit the number of request/response rows it stores.

  ```python
  SILKY_MAX_RECORDED_REQUESTS = 10**4
  ```

  The garbage collection is only run on a percentage of requests to reduce overhead.  It can be adjusted with this config:

  ```python
  SILKY_MAX_RECORDED_REQUESTS_CHECK_PERCENT = 10
  ```

  In case you want decouple silk's garbage collection from your webserver's request processing, set SILKY_MAX_RECORDED_REQUESTS_CHECK_PERCENT=0 and trigger it manually, e.g. in a cron job:

  ```bash
  python manage.py silk_request_garbage_collect
  ```



  To enable query analysis when supported by the dbms a config var can be set in order to execute queries with the analyze features.

  ```python
  SILKY_ANALYZE_QUERIES = True
  ```

  **Warning:** This setting may cause the database to execute the same query twice, depending on the backend. For instance, `EXPLAIN ANALYZE` in Postgres will [actually execute the query](https://www.postgresql.org/docs/current/sql-explain.html), which may result in unexpected data updates. Set this to True with caution.

  To pass additional params for profiling when supported by the dbms (e.g. VERBOSE, FORMAT JSON), you can do this in the following manner.

  ```python
  SILKY_EXPLAIN_FLAGS = {'format':'JSON', 'costs': True}
  ```




  By default, Silk is filtering values that contains the following keys (they are case insensitive)

  ```python
  SILKY_SENSITIVE_KEYS = {'username', 'api', 'token', 'key', 'secret', 'password', 'signature'}
  ```

  But sometimes, you might want to have your own sensitive keywords, then above configuration can be modified

  ```python
  SILKY_SENSITIVE_KEYS = {'custom-password'}
  ```




  A management command will wipe out all logged data:

  ```bash
  python manage.py silk_clear_request_log
  ```



  [![Jazzband](https://jazzband.co/static/img/jazzband.svg)](https://jazzband.co/)

  This is a [Jazzband](https://jazzband.co/) project. By contributing you agree to abide by the [Contributor Code of Conduct](https://jazzband.co/about/conduct) and follow the [guidelines](https://jazzband.co/about/guidelines).



  Silk features a project named `project` that can be used for `silk` development. It has the `silk` code symlinked so
  you can work on the sample `project` and on the `silk` package at the same time.

  In order to setup local development you should first install all the dependencies for the test `project`. From the
  root of the `project` directory:

  ```bash
  pip install -r requirements.txt
  ```

  You will also need to install `silk`'s dependencies. From the root of the git repository:

  ```bash
  pip install -e .
  ```

  At this point your virtual environment should have everything it needs to run both the sample `project` and
  `silk` successfully.

  Before running, you must set the `DB_ENGINE` and `DB_NAME` environment variables:

  ```bash
  export DB_ENGINE=sqlite3
  export DB_NAME=db.sqlite3
  ```

  For other combinations, check [`tox.ini`](./tox.ini).

  Now from the root of the sample `project` apply the migrations

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

  Now from the root of the sample `project` directory start the django server

  ```bash
  python manage.py runserver
  ```



  ```bash
  cd project
  python manage.py test
  ```

  Happy profiling!


pkgId: 0e7c60bc95dea507a26c79e3f30e1923fd63b7048086b1ab5b51b806b25657c4
name: python-django-simple-captcha
arch: src
version: 0.5.17
epoch: 0
release: 1
summary: A very simple, yet powerful, Django captcha application
url: https://github.com/mbi/django-simple-captcha
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fd5ffce4-e05a-4f80-9658-59884e3f5e40
location_href: 00013718-python-django-simple-captcha/python-django-simple-captcha-0.5.17-1.src.rpm
checksum_type: sha256
description:
  *********************
  Django Simple Captcha
  *********************

  .. image:: https://github.com/mbi/django-simple-captcha/actions/workflows/test.yml/badge.svg
    :target: https://github.com/mbi/django-simple-captcha/actions/workflows/test.yml

  .. image:: https://img.shields.io/pypi/v/django-simple-captcha
    :target: https://pypi.org/project/django-simple-captcha/

  .. image:: https://img.shields.io/pypi/l/django-simple-captcha
    :target: https://github.com/mbi/django-simple-captcha/blob/master/LICENSE


  Django Simple Captcha is an extremely simple, yet highly customizable Django application to add captcha images to any Django form.

  .. image:: http://django-simple-captcha.readthedocs.io/en/latest/_images/captcha3.png

  Features
  ++++++++

  * Very simple to setup and deploy, yet very configurable
  * Can use custom challenges (e.g. random chars, simple math, dictionary word, ...)
  * Custom generators, noise and filter functions alter the look of the generated image
  * Supports text-to-speech audio output of the challenge text, for improved accessibility
  * Ajax refresh

  Requirements
  ++++++++++++

  * Django 2.2+, Python3.6+
  * A recent version of the Pillow compiled with FreeType support
  * Flite is required for text-to-speech (audio) output, but not mandatory

  Documentation
  +++++++++++++

  Read the `documentation online <http://django-simple-captcha.readthedocs.org/en/latest/>`_.


pkgId: 65b5f41df250cd018a7c93b61c02b994ed6f4fca2095b87eb0edf74471833a7b
name: python-django-solo
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: Django Solo helps working with singletons
url: https://github.com/lazybird/django-solo/
rpm_license: Creative Commons Attribution 3.0 Unported
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ede7625b-cb08-4a7e-8233-7b97e2451be1
location_href: 00012013-python-django-solo/python-django-solo-2.0.0-1.src.rpm
checksum_type: sha256
description:
  <a href="https://pypi.org/project/django-solo/" alt="Current version on PyPi"><img src="https://img.shields.io/pypi/v/django-solo.svg" /></a>
      +---------------------------+
      |                           |
      |                           |
      |             \             | Django Solo helps working with singletons:
      |             /\            | database tables that only have one row.
      |           >=)'>           | Singletons are useful for things like global
      |             \/            | settings that you want to edit from the admin
      |             /             | instead of having them in Django settings.py.
      |                           |
      |                           |
      +---------------------------+


pkgId: c0086a05d2a775973a8bf259fdeee44c0a713909d1c97e882e5c0de73093b585
name: python-django-splash
arch: src
version: 1.2.1
epoch: 0
release: 1
summary: Splash screen middleware for Django apps
url: https://github.com/edx/django-splash
rpm_license: Apache Software License 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-801bba6f-0ce3-4bc5-b1f7-95b79a21077f
location_href: 00014056-python-django-splash/python-django-splash-1.2.1-1.src.rpm
checksum_type: sha256
description:
  |pypi-badge| |ci-badge| |codecov-badge| |pyversions-badge|
  |license-badge|
  Splash screen middleware for Django apps


pkgId: 3ae617ce11c1ae7e11f2e83d2b4665544e39c4d77ef363025cde4a3d5d027dda
name: python-django-split-settings
arch: src
version: 1.2.0
epoch: 0
release: 1
url: https://django-split-settings.readthedocs.io
rpm_license: BSD-2-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-767a136e-e387-4815-84e6-c498561bea0a
location_href: 00012561-python-django-split-settings/python-django-split-settings-1.2.0-1.src.rpm
checksum_type: sha256
summary:
  Organize Django settings into multiple files and directories. Easily override and modify settings. Use wildcards and optional settings files.

description:
  [![wemake.services](https://img.shields.io/badge/%20-wemake.services-green.svg?label=%20&logo=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAALGPC%2FxhBQAAAAFzUkdCAK7OHOkAAAAbUExURQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP%2F%2F%2F5TvxDIAAAAIdFJOUwAjRA8xXANAL%2Bv0SAAAADNJREFUGNNjYCAIOJjRBdBFWMkVQeGzcHAwksJnAPPZGOGAASzPzAEHEGVsLExQwE7YswCb7AFZSF3bbAAAAABJRU5ErkJggg%3D%3D)](https://wemake.services)
  [![test](https://github.com/sobolevn/django-split-settings/workflows/test/badge.svg?branch=master&event=push)](https://github.com/sobolevn/django-split-settings/actions?query=workflow%3Atest)
  [![codecov](https://codecov.io/gh/sobolevn/django-split-settings/branch/master/graph/badge.svg)](https://codecov.io/gh/sobolevn/django-split-settings)
  [![Docs](https://readthedocs.org/projects/django-split-settings/badge/?version=latest)](http://django-split-settings.readthedocs.io/en/latest/?badge=latest)
  [![Python Version](https://img.shields.io/pypi/pyversions/django-split-settings.svg)](https://pypi.org/project/django-split-settings/)
  [![wemake-python-styleguide](https://img.shields.io/badge/style-wemake-000000.svg)](https://github.com/wemake-services/wemake-python-styleguide)
  Organize Django settings into multiple files and directories. Easily
  override and modify settings. Use wildcards in settings file paths
  and mark settings files as optional.
  Read [this blog post](https://sobolevn.me/2017/04/managing-djangos-settings)
  for more information.
  Also, check this [example project](https://github.com/wemake-services/wemake-django-template).

  While this package will most likely work with the most versions of `django`, we [officially support](https://github.com/sobolevn/django-split-settings/blob/master/.github/workflows/test.yml):
  - 2.2
  - 3.2
  - 4.0
  - 4.1
  This package has no dependencies itself.
  In case you need older `python` / `django` versions support,
  then consider using older versions of `django-split-settings`.

  ```bash
  pip install django-split-settings
  ```

  Replace your existing `settings.py` with a list of components that
  make up your Django settings. Preferably create a settings package
  that contains all the files.
  Here's a minimal example:
  ```python
  from split_settings.tools import optional, include
  include(
      'components/base.py',
      'components/database.py',
      optional('local_settings.py')
  )
  ```
  In the example, the files `base.py` and `database.py` are included
  in that order from the subdirectory called `components/`.
  `local_settings.py` in the same directory is included if it exists.
  **Note:** The local context is passed on to each file, so each
  following file can access and modify the settings declared in the
  previous files.
  We also made an in-depth [tutorial](https://sobolevn.me/2017/04/managing-djangos-settings).

  You can use wildcards in file paths:
  ```python
  include('components/my_app/*.py')
  ```
  Note that files are included in the order that `glob` returns them,
  probably in the same order as what `ls -U` would list them. The
  files are NOT in alphabetical order.
  You can modify common settings in environment settings simply importing them
  ```python

  from components.base import INSTALLED_APPS
  INSTALLED_APPS += (
    'raven.contrib.django.raven_compat',
  )
  ```

  Read the [CONTRIBUTING.md](https://github.com/sobolevn/django-split-settings/blob/master/CONTRIBUTING.md) file.

  See [CHANGELOG.md](https://github.com/sobolevn/django-split-settings/blob/master/CHANGELOG.md) file.


pkgId: 539a6275e71c297343a60e6ebe7b846efce346ee2d884740db5fa06d53f5ad2a
name: python-django-sql-explorer
arch: src
version: 3.1.1
epoch: 0
release: 1
summary: A pluggable app that allows users (admins) to execute SQL, view, and export the results.
url: https://github.com/groveco/django-sql-explorer
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-483e4e48-2453-4f92-a632-1a8bcfde6cc8
location_href: 00013013-python-django-sql-explorer/python-django-sql-explorer-3.1.1-1.src.rpm
checksum_type: sha256
description:
  SQL Explorer aims to make the flow of data between people fast,
  simple, and confusion-free. It is a Django-based application that you
  can add to an existing Django site, or use as a standalone business
  intelligence tool.
  Quickly write and share SQL queries in a simple, usable SQL editor,
  preview the results in the browser, share links, download CSV, JSON,
  or Excel files (and even expose queries as API endpoints, if desired),
  and keep the information flowing!
  Comes with support for multiple connections, to many different SQL
  database types, a schema explorer, query history (e.g. lightweight
  version control), a basic security model, in-browser pivot tables, and
  more.
  SQL Explorer values simplicity, intuitive use, unobtrusiveness,
  stability, and the principle of least surprise.
  SQL Explorer is inspired by any number of great query and
  reporting tools out there.
  The original idea came from Stack Exchange's `Data Explorer
  <http://data.stackexchange.com/stackoverflow/queries>`_, but also owes
  credit to similar projects like `Redash <http://redash.io/>`_ and
  `Blazer <https://github.com/ankane/blazer>`_.
  You can read the full documentation `here <https://django-sql-explorer.readthedocs.io/en/latest/>`_
  Sql Explorer is MIT licensed, and pull requests are welcome.
  **A view of a query**
  **Viewing all queries**
  **Quick access to DB schema info**
  **Snapshot query results to S3 & download as csv**


pkgId: 47f7e4933e5f4d18f727d53075d984c7af870a3eab6f0f1fb795250a22978be3
name: python-django-storages
arch: src
version: 1.13.2
epoch: 0
release: 1
summary: Support for many storage backends in Django
url: https://github.com/jschneier/django-storages
rpm_license: BSD-3-Clause
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-bac4cd7b-dfd6-4e53-b8db-8b4be5e1ced9
location_href: 00003490-python-django-storages/python-django-storages-1.13.2-1.src.rpm
checksum_type: sha256
description:
  Installing from PyPI is as easy as doing:
    pip install django-storages
  If you'd prefer to install from source (maybe there is a bugfix in master that
  hasn't been released yet) then the magic incantation you are looking for is:
    pip install -e 'git+https://github.com/jschneier/django-storages.git#egg=django-storages'
  Once that is done set ``DEFAULT_FILE_STORAGE`` to the backend of your choice.
  If, for example, you want to use the boto3 backend you would set:
    DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'
  If you are using the ``FileSystemStorage`` as your storage management class in your models ``FileField`` fields, remove them
  and don't specify any storage parameter. That way, the ``DEFAULT_FILE_STORAGE`` class will be used by default in your field.
  For example, if you have a `photo` field defined as:
      photo = models.FileField(
          storage=FileSystemStorage(location=settings.MEDIA_ROOT),
          upload_to='photos',
      )
  Set it to just:
      photo = models.FileField(
          upload_to='photos',
      )
  There are also a number of settings available to control how each storage backend functions,
  please consult the documentation for a comprehensive list.


pkgId: fb65bc1682751db0acdf6fcaa706759e832f5b74d8df76fa5ca3fe61e09f0023
name: python-django-stubs
arch: src
version: 1.16.0
epoch: 0
release: 1
summary: Mypy stubs for Django
url: https://github.com/typeddjango/django-stubs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-e63fded9-c7d6-4389-b6bc-5ddca1d90183
location_href: 00010219-python-django-stubs/python-django-stubs-1.16.0-1.src.rpm
checksum_type: sha256
description:
  <img src="http://mypy-lang.org/static/mypy_light.svg" alt="mypy logo" width="300px"/>



  [![Build status](https://github.com/typeddjango/django-stubs/workflows/test/badge.svg?branch=master&event=push)](https://github.com/typeddjango/django-stubs/actions?query=workflow%3Atest)
  [![Checked with mypy](http://www.mypy-lang.org/static/mypy_badge.svg)](http://mypy-lang.org/)
  [![Gitter](https://badges.gitter.im/mypy-django/Lobby.svg)](https://gitter.im/mypy-django/Lobby)
  [![StackOverflow](https://shields.io/badge/ask-stackoverflow-orange?logo=stackoverflow)](https://stackoverflow.com/questions/tagged/django-stubs)

  This package contains [type stubs](https://www.python.org/dev/peps/pep-0561/) and a custom mypy plugin to provide more precise static types and type inference for Django framework. Django uses some Python "magic" that makes having precise types for some code patterns problematic. This is why we need this project. The final goal is to be able to get precise types for most common patterns.



  ```bash
  pip install django-stubs[compatible-mypy]
  ```

  To make mypy aware of the plugin, you need to add

  ```ini
  [mypy]
  plugins =
      mypy_django_plugin.main

  [mypy.plugins.django-stubs]
  django_settings_module = "myproject.settings"
  ```

  in your `mypy.ini` or `setup.cfg` [file](https://mypy.readthedocs.io/en/latest/config_file.html).

  [pyproject.toml](https://mypy.readthedocs.io/en/stable/config_file.html#using-a-pyproject-toml-file) configurations are also supported:

  ```toml
  [tool.mypy]
  plugins = ["mypy_django_plugin.main"]

  [tool.django-stubs]
  django_settings_module = "myproject.settings"
  ```

  Two things happening here:

  1. We need to explicitly list our plugin to be loaded by `mypy`
  2. Our plugin also requires `django` settings module (what you put into `DJANGO_SETTINGS_MODULE` variable) to be specified

  This fully working [typed boilerplate](https://github.com/wemake-services/wemake-django-template) can serve you as an example.



  We rely on different `django` and `mypy` versions:

  | django-stubs | mypy version | django version | python version
  |--------------| ---- | ---- | ---- |
  | 1.16.0       | 1.1.x | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.15.0       | 1.0.x | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.14.0       | 0.990+ | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.13.0       | 0.980+ | 3.2.x or 4.0.x or 4.1.x | ^3.7
  | 1.12.0       | 0.931+ | 3.2.x or 4.0.x | ^3.7
  | 1.11.0       | 0.931+ | 3.2.x | ^3.7
  | 1.10.0       | 0.931+ | 3.2.x | ^3.7
  | 1.9.0        | 0.910 | 3.2.x | ^3.6
  | 1.8.0        | 0.812 | 3.1.x | ^3.6
  | 1.7.0        | 0.790 | 2.2.x \|\| 3.x | ^3.6
  | 1.6.0        | 0.780 | 2.2.x \|\| 3.x | ^3.6
  | 1.5.0        | 0.770 | 2.2.x \|\| 3.x | ^3.6
  | 1.4.0        | 0.760 | 2.2.x \|\| 3.x | ^3.6
  | 1.3.0        | 0.750 | 2.2.x \|\| 3.x | ^3.6
  | 1.2.0        | 0.730 | 2.2.x | ^3.6
  | 1.1.0        | 0.720 | 2.2.x | ^3.6
  | 0.12.x       | old semantic analyzer (<0.711), dmypy support | 2.1.x | ^3.6





  No, it is not. We are independent from Django at the moment.
  There's a [proposal](https://github.com/django/deps/pull/65) to merge our project into the Django itself.
  You can show your support by liking the PR.



  Yes, it is! This project does not affect your runtime at all.
  It only affects `mypy` type checking process.

  But, it does not make any sense to use this project without `mypy`.



  The current implementation uses Django's runtime to extract information about models, so it might crash if your installed apps or `models.py` are broken.

  In other words, if your `manage.py runserver` crashes, mypy will crash too.
  You can also run `mypy` with [`--tb`](https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-show-traceback)
  option to get extra information about the error.



  You can get a `TypeError: 'type' object is not subscriptable`
  when you will try to use `QuerySet[MyModel]`, `Manager[MyModel]` or some other Django-based Generic types.

  This happens because these Django classes do not support [`__class_getitem__`](https://www.python.org/dev/peps/pep-0560/#class-getitem) magic method in runtime.

  1. You can go with our [`django_stubs_ext`](https://github.com/typeddjango/django-stubs/tree/master/django_stubs_ext) helper, that patches all the types we use as Generic in django.

     Install it:

     ```bash
     pip install django-stubs-ext  # as a production dependency
     ```

     And then place in your top-level settings:

     ```python
     import django_stubs_ext

     django_stubs_ext.monkeypatch()
     ```

     Note: This monkey patching approach will only work when using Python 3.7 and higher, when the `__class_getitem__` magic method was introduced.

     You can add extra types to patch with `django_stubs_ext.monkeypatch(extra_classes=[YourDesiredType])`

  2. You can use strings instead: `'QuerySet[MyModel]'` and `'Manager[MyModel]'`, this way it will work as a type for `mypy` and as a regular `str` in runtime.



  Django's built in [`HttpRequest`](https://docs.djangoproject.com/en/4.1/ref/request-response/#django.http.HttpRequest) has the attribute `user` that resolves to the type

  ```python
  Union[User, AnonymousUser]
  ```

  where `User` is the user model specified by the `AUTH_USER_MODEL` setting.

  If you want a `HttpRequest` that you can type-annotate with where you know that the user is authenticated you can subclass the normal `HttpRequest` class like so:

  ```python
  from django.http import HttpRequest
  from my_user_app.models import MyUser


  class AuthenticatedHttpRequest(HttpRequest):
      user: MyUser
  ```

  And then use `AuthenticatedHttpRequest` instead of the standard `HttpRequest` for when you know that the user is authenticated. For example in views using the `@login_required` decorator.



  If you are using `MyQuerySet.as_manager()`:

  Example:

  ```python
  from django.db import models

  class MyModelQuerySet(models.QuerySet):
      pass


  class MyModel(models.Model):
      bar = models.IntegerField()
      objects = MyModelQuerySet.as_manager()


  def use_my_model() -> int:
      foo = MyModel.objects.get(id=1) # Should now be `MyModel`
      return foo.xyz # Gives an error
  ```

  Or if you're using `Manager.from_queryset`:

  Example:

  ```python
  from django.db import models


  class MyModelQuerySet(models.QuerySet):
      pass


  MyModelManager = models.Manager.from_queryset(MyModelQuerySet)


  class MyModel(models.Model):
      bar = models.IntegerField()
      objects = MyModelManager()


  def use_my_model() -> int:
      foo = MyModel.objects.get(id=1) # Should now be `MyModel`
      return foo.xyz # Gives an error
  ```



  If you declare your custom managers without generics and override built-in
  methods you might see an error message about incompatible error messages,
  something like this:

  ```python
  from django.db import models

  class MyManager(model.Manager):
      def create(self, **kwargs) -> "MyModel":
          pass
  ```

  will cause this error message:

  > error: Return type "MyModel" of "create" incompatible with return type "_T" in supertype "BaseManager"

  This is happening because the `Manager` class is generic, but without
  specifying generics the built-in manager methods are expected to return the
  generic type of the base manager, which is any model. To fix this issue you
  should declare your manager with your model as the type variable:

  ```python
  class MyManager(models.Manager["MyModel"]):
      ...
  ```



  Django-stubs provides a special type, `django_stubs_ext.WithAnnotations[Model]`, which indicates that the `Model` has
  been annotated, meaning it allows getting/setting extra attributes on the model instance.

  Optionally, you can provide a `TypedDict` of these attributes,
  e.g. `WithAnnotations[MyModel, MyTypedDict]`, to specify which annotated attributes are present.

  Currently, the mypy plugin can recognize that specific names were passed to `QuerySet.annotate` and
  include them in the type, but does not record the types of these attributes.

  The knowledge of the specific annotated fields is not yet used in creating more specific types for `QuerySet`'s
  `values`, `values_list`, or `filter` methods, however knowledge that the model was annotated _is_ used to create a
  broader type result type for `values`/`values_list`, and to allow `filter`ing on any field.

  ```python
  from typing import TypedDict
  from django_stubs_ext import WithAnnotations
  from django.db import models
  from django.db.models.expressions import Value


  class MyModel(models.Model):
      username = models.CharField(max_length=100)


  def func(m: WithAnnotations[MyModel]) -> str:
      return m.asdf  # OK, since the model is annotated as allowing any attribute


  func(MyModel.objects.annotate(foo=Value("")).get(id=1))  # OK
  func(
      MyModel.objects.get(id=1)
  )  # Error, since this model will not allow access to any attribute


  class MyTypedDict(TypedDict):
      foo: str


  def func2(m: WithAnnotations[MyModel, MyTypedDict]) -> str:
      print(m.bar)  # Error, since field "bar" is not in MyModel or MyTypedDict.
      return m.foo  # OK, since we said field "foo" was allowed


  func(MyModel.objects.annotate(foo=Value("")).get(id=1))  # OK
  func(MyModel.objects.annotate(bar=Value("")).get(id=1))  # Error
  ```



  A limitation of making `QuerySet` generic is that you can not use
  it for `isinstance` checks.

  ```python
  from django.db.models.query import QuerySet

  def foo(obj: object) -> None:
      if isinstance(obj, QuerySet): # Error: Parameterized generics cannot be used with class or instance checks
          ...
  ```

  To get around with this issue without making `QuerySet` non-generic,
  Django-stubs provides `django_stubs_ext.QuerySetAny`, a non-generic
  variant of `QuerySet` suitable for runtime type checking:

  ```python
  from django_stubs_ext import QuerySetAny

  def foo(obj: object) -> None:
      if isinstance(obj, QuerySetAny):  # OK
          ...
  ```



  The lazy translation functions of Django (such as `gettext_lazy`) return a `Promise` instead of `str`. These two types [cannot be used interchangeably](https://github.com/typeddjango/django-stubs/pull/1139#issuecomment-1232167698). The return type of these functions was therefore [changed](https://github.com/typeddjango/django-stubs/pull/689) to reflect that.

  If you encounter this error in your own code, you can either cast the `Promise` to `str` (causing the translation to be evaluated), or use the `StrPromise` or `StrOrPromise` types from `django-stubs-ext` in type hints. Which solution to choose depends depends on the particular case. See [working with lazy translation objects](https://docs.djangoproject.com/en/4.1/topics/i18n/translation/#working-with-lazy-translation-objects) in the Django documentation for more information.

  If this is reported on Django code, please report an issue or open a pull request to fix the type hints.



  - [`awesome-python-typing`](https://github.com/typeddjango/awesome-python-typing) - Awesome list of all typing-related things in Python.
  - [`djangorestframework-stubs`](https://github.com/typeddjango/djangorestframework-stubs) - Stubs for Django REST Framework.
  - [`pytest-mypy-plugins`](https://github.com/typeddjango/pytest-mypy-plugins) - `pytest` plugin that we use for testing `mypy` stubs and plugins.
  - [`wemake-django-template`](https://github.com/wemake-services/wemake-django-template) - Create new typed Django projects in seconds.



  We have Gitter here: <https://gitter.im/mypy-django/Lobby>
  If you think you have more generic typing issue, please refer to <https://github.com/python/mypy> and their Gitter.



  This project is open source and community driven. As such we encourage contributions big and small. You can contribute by doing any of the following:

  1. Contribute code (e.g. improve stubs, add plugin capabilities, write tests etc) - to do so please follow the [contribution guide](./CONTRIBUTING.md).
  2. Assist in code reviews and discussions in issues.
  3. Identify bugs and issues and report these
  4. Ask and answer questions on [StackOverflow](https://stackoverflow.com/questions/tagged/django-stubs)

  You can always also reach out in gitter to discuss your contributions!


pkgId: cc4f335507d10be26d469db3b6e43f0539e4ee54e028548781ceaf8c8ea69bf2
name: python-django-stubs-ext
arch: src
version: 0.8.0
epoch: 0
release: 1
summary: Monkey-patching and extensions for django-stubs
url: https://github.com/typeddjango/django-stubs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-fe0f837c-5556-400b-aa35-4f9aa5b68c11
location_href: 00010607-python-django-stubs-ext/python-django-stubs-ext-0.8.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.com/typeddjango/django-stubs.svg?branch=master)](https://travis-ci.com/typeddjango/django-stubs)
  [![Checked with mypy](http://www.mypy-lang.org/static/mypy_badge.svg)](http://mypy-lang.org/)
  [![Gitter](https://badges.gitter.im/mypy-django/Lobby.svg)](https://gitter.im/mypy-django/Lobby)


  This package contains extensions and monkey-patching functions for the [django-stubs](https://github.com/typeddjango/django-stubs) package. Certain features of django-stubs (i.e. generic django classes that don't define the `__class_getitem__` method) require runtime monkey-patching, which can't be done with type stubs. These extensions were split into a separate package so library consumers don't need `mypy` as a runtime dependency ([#526](https://github.com/typeddjango/django-stubs/pull/526#pullrequestreview-525798031)).



  ```bash
  pip install django-stubs-ext
  ```



  In your Django application, use the following code:

  ```py
  import django_stubs_ext

  django_stubs_ext.monkeypatch()
  ```

  This only needs to be called once, so the call to `monkeypatch` should be placed in your top-level settings.
  Real-life example [can be found here](https://github.com/wemake-services/wemake-django-template/blob/5bf1569e2710e11befc6991893f94419136d74bd/%7B%7Bcookiecutter.project_name%7D%7D/server/settings/__init__.py#L14-L19).



  Since django-stubs supports multiple Django versions, this package takes care to only monkey-patch the features needed by your django version, and decides which features to patch at runtime. This is completely safe, as (currently) we only add a `__class_getitem__` method that does nothing:

  ```py
  @classmethod
  def __class_getitem__(cls, *args, **kwargs):
      return cls
  ```



  For help with django-stubs, please view the main repository at <https://github.com/typeddjango/django-stubs>

  We have a Gitter chat here: <https://gitter.im/mypy-django/Lobby>
  If you think you have a more generic typing issue, please refer to <https://github.com/python/mypy> and their Gitter.



  The django-stubs-ext package is part of the [django-stubs](https://github.com/typeddjango/django-stubs) monorepo. If you would like to contribute, please view the django-stubs [contribution guide](https://github.com/typeddjango/django-stubs/blob/master/CONTRIBUTING.md).

  You can always also reach out in gitter to discuss your contributions!


pkgId: 53e7910f26d4ae752f49957f3aad023696485f36f3c0bb3733cbe538d1164889
name: python-django-tables2
arch: src
version: 2.5.3
epoch: 0
release: 1
summary: Table/data-grid framework for Django
url: https://github.com/jieter/django-tables2/
rpm_license: Simplified BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-75e0b147-a285-4856-a655-0e97f119305d
location_href: 00003496-python-django-tables2/python-django-tables2-2.5.3-1.src.rpm
checksum_type: sha256
description:
  [![Latest PyPI version](https://badge.fury.io/py/django-tables2.svg)](https://pypi.python.org/pypi/django-tables2)
  [![Any color you like](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/ambv/black)

  django-tables2 simplifies the task of turning sets of data into HTML tables. It
  has native support for pagination and sorting. It does for HTML tables what
  `django.forms` does for HTML forms. e.g.

  - Available on pypi as [django-tables2](https://pypi.python.org/pypi/django-tables2)
  - Tested against currently supported versions of Django
    [and supported python 3 versions Django supports](https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django).
  - [Documentation on readthedocs.org](https://django-tables2.readthedocs.io/en/latest/)
  - [Bug tracker](http://github.com/jieter/django-tables2/issues)

  Features:

  - Any iterable can be a data-source, but special support for Django `QuerySets` is included.
  - The builtin UI does not rely on JavaScript.
  - Support for automatic table generation based on a Django model.
  - Supports custom column functionality via subclassing.
  - Pagination.
  - Column based table sorting.
  - Template tag to enable trivial rendering to HTML.
  - Generic view mixin.

  ![An example table rendered using django-tables2](https://cdn.rawgit.com/jieter/django-tables2/master/docs/img/example.png)

  ![An example table rendered using django-tables2 and bootstrap theme](https://cdn.rawgit.com/jieter/django-tables2/master/docs/img/bootstrap.png)

  ![An example table rendered using django-tables2 and semantic-ui theme](
  https://cdn.rawgit.com/jieter/django-tables2/master/docs/img/semantic.png)



  Start by adding `django_tables2` to your `INSTALLED_APPS` setting like this:

  ```python
  INSTALLED_APPS = (
      ...,
      "django_tables2",
  )
  ```

  Creating a table for a model `Simple` is as simple as:

  ```python
  import django_tables2 as tables

  class SimpleTable(tables.Table):
      class Meta:
          model = Simple
  ```
  This would then be used in a view:

  ```python
  class TableView(tables.SingleTableView):
      table_class = SimpleTable
      queryset = Simple.objects.all()
      template_name = "simple_list.html"
  ```
  And finally in the template:

  ```
  {% load django_tables2 %}
  {% render_table table %}
  ```

  This example shows one of the simplest cases, but django-tables2 can do a lot more!
  Check out the [documentation](https://django-tables2.readthedocs.io/en/latest/) for more details.


pkgId: 6615dd28edf1796a7f44e6e059428909c02cd60e5ec635df549cd4926b02a42b
name: python-django-taggit
arch: src
version: 3.1.0
epoch: 0
release: 1
summary: django-taggit is a reusable Django application for simple tagging.
url: https://github.com/jazzband/django-taggit
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-2461dcdc-3027-4d85-bbb4-e68b765f38e5
location_href: 00003498-python-django-taggit/python-django-taggit-3.1.0-1.src.rpm
checksum_type: sha256
description:
  This is a `Jazzband <https://jazzband.co>`_ project. By contributing you agree
  to abide by the `Contributor Code of Conduct
  <https://jazzband.co/about/conduct>`_ and follow the `guidelines
  <https://jazzband.co/about/guidelines>`_.
  ``django-taggit`` a simpler approach to tagging with Django.  Add ``"taggit"`` to your
  ``INSTALLED_APPS`` then just add a TaggableManager to your model and go:
      from django.db import models
      from taggit.managers import TaggableManager
      class Food(models.Model):
          
          tags = TaggableManager()
  Then you can use the API like so:
      >>> apple = Food.objects.create(name="apple")
      >>> apple.tags.add("red", "green", "delicious")
      >>> apple.tags.all()
      [<Tag: red>, <Tag: green>, <Tag: delicious>]
      >>> apple.tags.remove("green")
      >>> apple.tags.all()
      [<Tag: red>, <Tag: delicious>]
      >>> Food.objects.filter(tags__name__in=["red"])
      [<Food: apple>, <Food: cherry>]
  Tags will show up for you automatically in forms and the admin.
  ``django-taggit`` requires Django 3.2 or greater.
  For more info check out the `documentation
  <https://django-taggit.readthedocs.io/>`_. And for questions about usage or
  development you can create an issue on Github (if your question is about
  usage please add the `question` tag).


pkgId: 731ad55b2eea0efdec0afa469e4605d712d1bb6b2beaaae5ce22fc21ba832e8f
name: python-django-taggit-serializer
arch: src
version: 0.1.7
epoch: 0
release: 1
summary: The Django Taggit serializer for tDjango REST Framework
url: https://github.com/glemmaPaul/django-taggit-serializer
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-61b0f1ba-0f4e-4e63-b6e9-8f98e3200658
location_href: 00003499-python-django-taggit-serializer/python-django-taggit-serializer-0.1.7-1.src.rpm
checksum_type: sha256
description:
  The Django Taggit Serializer for the DjangoREST Framework developers. Installation can be found on https://github.com/glemmaPaul/django-taggit-serializer


pkgId: 0148337786caa7068be14249346ef4d068b5b67b657e03e5c6d1c67acb2e7c12
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-c77f6966-e3de-4a7f-a4da-c5bfd3139ca5
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: ef9088112be85a3bafcfcf1311a16c2113bfc4b366ea3a96755fd46295c304fa
name: python-django-test-migrations
arch: src
version: 1.2.0
epoch: 0
release: 1
summary: Test django schema and data migrations, including ordering
url: https://github.com/wemake-services/django-test-migrations
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-ae9e0d62-a3cb-41a4-930c-bedb8fdb93a3
location_href: 00013005-python-django-test-migrations/python-django-test-migrations-1.2.0-1.src.rpm
checksum_type: sha256
description:
  [![wemake.services](https://img.shields.io/badge/%20-wemake.services-green.svg?label=%20&logo=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAALGPC%2FxhBQAAAAFzUkdCAK7OHOkAAAAbUExURQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP%2F%2F%2F5TvxDIAAAAIdFJOUwAjRA8xXANAL%2Bv0SAAAADNJREFUGNNjYCAIOJjRBdBFWMkVQeGzcHAwksJnAPPZGOGAASzPzAEHEGVsLExQwE7YswCb7AFZSF3bbAAAAABJRU5ErkJggg%3D%3D)](https://wemake.services)
  [![Build status](https://github.com/wemake-services/django-test-migrations/workflows/test/badge.svg?branch=master&event=push)](https://github.com/wemake-services/django-test-migrations/actions?query=workflow%3Atest)
  [![codecov](https://codecov.io/gh/wemake-services/django-test-migrations/branch/master/graph/badge.svg)](https://codecov.io/gh/wemake-services/django-test-migrations)
  [![Python Version](https://img.shields.io/pypi/pyversions/django-test-migrations.svg)](https://pypi.org/project/django-test-migrations/)
  ![PyPI - Django Version](https://img.shields.io/pypi/djversions/django-test-migrations)
  [![wemake-python-styleguide](https://img.shields.io/badge/style-wemake-000000.svg)](https://github.com/wemake-services/wemake-python-styleguide)




  - Allows to test `django` schema and data migrations
  - Allows to test both forward and rollback migrations
  - Allows to test the migrations order
  - Allows to test migration names
  - Allows to test database configuration
  - Fully typed with annotations and checked with `mypy`, [PEP561 compatible](https://www.python.org/dev/peps/pep-0561/)
  - Easy to start: has lots of docs, tests, and tutorials

  Read the [announcing post](https://sobolevn.me/2019/10/testing-django-migrations).
  See real-world [usage example](https://github.com/wemake-services/wemake-django-template).




  ```bash
  pip install django-test-migrations
  ```

  We support several `django` versions:

  - `1.11`
  - `2.2`
  - `3.1`
  - `3.2`
  - `4.0`

  Other versions might work too, but they are not officially supported.




  Testing migrations is not a frequent thing in `django` land.
  But, sometimes it is totally required. When?

  When we do complex schema or data changes
  and what to be sure that existing data won't be corrupted.
  We might also want to be sure that all migrations can be safely rolled back.
  And as a final touch we want to be sure that migrations
  are in the correct order and have correct dependencies.



  To test all migrations we have a [`Migrator`](https://github.com/wemake-services/django-test-migrations/blob/master/django_test_migrations/migrator.py) class.

  It has three methods to work with:

  - `.apply_initial_migration()` which takes app and migration names to generate
    a state before the actual migration happens. It creates the `before state`
    by applying all migrations up to and including the ones passed as an argument.

  - `.apply_tested_migration()` which takes app and migration names to perform the
    actual migration

  - `.reset()` to clean everything up after we are done with testing

  So, here's an example:

  ```python
  from django_test_migrations.migrator import Migrator

  migrator = Migrator(database='default')








  old_state = migrator.apply_initial_migration(('main_app', '0001_initial'))
  SomeItem = old_state.apps.get_model('main_app', 'SomeItem')


  SomeItem.objects.create(string_field='a')
  assert len(SomeItem._meta.get_fields()) == 2  # id + string_field


  new_state = migrator.apply_tested_migration(
      ('main_app', '0002_someitem_is_clean'),
  )
  SomeItem = new_state.apps.get_model('main_app', 'SomeItem')


  assert SomeItem.objects.filter(is_clean=True).count() == 0
  assert len(SomeItem._meta.get_fields()) == 3  # id + string_field + is_clean


  migrator.reset()
  ```

  That was an example of a forward migration.



  The thing is that you can also test backward migrations.
  Nothing really changes except migration names that you pass and your logic:

  ```python
  migrator = Migrator()


  old_state = migrator.apply_initial_migration(
      ('main_app', '0002_someitem_is_clean'),
  )
  SomeItem = old_state.apps.get_model('main_app', 'SomeItem')





  new_state = migrator.apply_tested_migration(('main_app', '0001_initial'))





  migrator.reset()
  ```



  Sometimes we also want to be sure that our migrations are in the correct order.
  And all our `dependecies = [...]` are correct.

  To achieve that we have [`plan.py`](https://github.com/wemake-services/django-test-migrations/blob/master/django_test_migrations/plan.py) module.

  That's how it can be used:

  ```python
  from django_test_migrations.plan import all_migrations, nodes_to_tuples

  main_migrations = all_migrations('default', ['main_app', 'other_app'])
  assert nodes_to_tuples(main_migrations) == [
      ('main_app', '0001_initial'),
      ('main_app', '0002_someitem_is_clean'),
      ('other_app', '0001_initial'),
      ('main_app', '0003_update_is_clean'),
      ('main_app', '0004_auto_20191119_2125'),
      ('other_app', '0002_auto_20191120_2230'),
  ]
  ```

  This way you can be sure that migrations
  and apps that depend on each other will be executed in the correct order.




  We support several test frameworks as first-class citizens.
  That's a testing tool after all!

  Note that the Django `post_migrate` signal's receiver list is cleared at
  the start of tests and restored afterwards. If you need to test your
  own `post_migrate` signals then attach/remove them during a test.



  We ship `django-test-migrations` with a `pytest` plugin
  that provides two convinient fixtures:

  - `migrator_factory` that gives you an opportunity
    to create `Migrator` classes for any database
  - `migrator` instance for the `'default'` database

  That's how it can be used:

  ```python
  import pytest

  @pytest.mark.django_db()
  def test_pytest_plugin_initial(migrator):
      """Ensures that the initial migration works."""
      old_state = migrator.apply_initial_migration(('main_app', None))

      with pytest.raises(LookupError):
          
          old_state.apps.get_model('main_app', 'SomeItem')

      new_state = migrator.apply_tested_migration(('main_app', '0001_initial'))
      
      SomeItem = new_state.apps.get_model('main_app', 'SomeItem')
      assert SomeItem.objects.filter(string_field='').count() == 0
  ```



  We also ship an integration with the built-in `unittest` framework.

  Here's how it can be used:

  ```python
  from django_test_migrations.contrib.unittest_case import MigratorTestCase

  class TestDirectMigration(MigratorTestCase):
      """This class is used to test direct migrations."""

      migrate_from = ('main_app', '0002_someitem_is_clean')
      migrate_to = ('main_app', '0003_update_is_clean')

      def prepare(self):
          """Prepare some data before the migration."""
          SomeItem = self.old_state.apps.get_model('main_app', 'SomeItem')
          SomeItem.objects.create(string_field='a')
          SomeItem.objects.create(string_field='a b')

      def test_migration_main0003(self):
          """Run the test itself."""
          SomeItem = self.new_state.apps.get_model('main_app', 'SomeItem')

          assert SomeItem.objects.count() == 2
          assert SomeItem.objects.filter(is_clean=True).count() == 1
  ```



  In CI systems it is important to get instant feedback. Running tests that
  apply database migration can slow down tests execution, so it is often a good
  idea to run standard, fast, regular unit tests without migrations in parallel
  with slower migrations tests.



  `django_test_migrations` adds `migration_test` marker to each test using
  `migrator_factory` or `migrator` fixture.
  To run only migrations test, use `-m` option:

  ```bash
  pytest -m migration_test  # runs only migraion tests
  pytest -m "not migration_test"  # runs all except migraion tests
  ```



  `django_test_migrations` adds `migration_test`
  [tag](https://docs.djangoproject.com/en/3.0/topics/testing/tools/#tagging-tests)
  to every `MigratorTestCase` subclass.
  To run only migrations tests, use `--tag` option:

  ```bash
  python mange.py test --tag=migration_test  # runs only migraion tests
  python mange.py test --exclude-tag=migration_test  # runs all except migraion tests
  ```




  `django_test_migrations` comes with 2 groups of Django's checks for:

  + detecting migrations scripts automatically generated names
  + validating some subset of database settings



  `django` generates migration names for you when you run `makemigrations`.
  And these names are bad ([read more](https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/) about why it is bad)!
  Just look at this: `0004_auto_20191119_2125.py`

  What does this migration do? What changes does it have?

  One can also pass `--name` attribute when creating migrations, but it is easy to forget.

  We offer an automated solution: `django` check
  that produces an error for each badly named migration.

  Add our check into your `INSTALLED_APPS`:

  ```python
  INSTALLED_APPS = [
      

      
      'django_test_migrations.contrib.django_checks.AutoNames',
  ]
  ```

  And then in your CI run:

  ```bash
  python manage.py check --deploy
  ```

  This way you will be safe from wrong names in your migrations.

  Do you have a migrations that cannot be renamed? Add them to the ignore list:

  ```python


  DTM_IGNORED_MIGRATIONS = {
      ('main_app', '0004_auto_20191119_2125'),
      ('dependency_app', '0001_auto_20201110_2100'),
  }
  ```

  And we won't complain about them.

  Or you can completely ignore entire app:

  ```python


  DTM_IGNORED_MIGRATIONS = {
      ('dependency_app', '*'),
      ('another_dependency_app', '*'),
  }
  ```



  Add our check to `INSTALLED_APPS`:

  ```python
  INSTALLED_APPS = [
      

      
      'django_test_migrations.contrib.django_checks.DatabaseConfiguration',
  ]
  ```

  Then just run `check` management command in your CI like listed in section
  above.




  You might also like:

  - [django-migration-linter](https://github.com/3YOURMIND/django-migration-linter) - Detect backward incompatible migrations for your django project.
  - [wemake-django-template](https://github.com/wemake-services/wemake-django-template/) - Bleeding edge django template focused on code quality and security with both `django-test-migrations` and `django-migration-linter` on board.




  This project is based on work of other awesome people:

  - [@asfaltboy](https://gist.github.com/asfaltboy/b3e6f9b5d95af8ba2cc46f2ba6eae5e2)
  - [@blueyed](https://gist.github.com/blueyed/4fb0a807104551f103e6)
  - [@fernandogrd](https://gist.github.com/blueyed/4fb0a807104551f103e6#gistcomment-1546191)
  - [@adamchainz](https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/)




  MIT.


pkgId: 831d708c1a207848e74cd5cb9f5432bccefe524bd1e2af4d29c4ab90741cf813
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-02268ea3-84d9-40fc-a7c5-78e568524582
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: 825c4a500ecd9a364c64f270154fa74ccd5326e010b37ec88041fc22eec06a88
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-02268ea3-84d9-40fc-a7c5-78e568524582
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: 4f1348469d7734fba4bf89b2429b06e26a7452dcb06953d331fb4f28f431f1ca
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-2daad724-ca12-44f0-8a50-223178c0a167
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: eaec86ebc0571e8fdca437c93ec834946ff4e29dcae83c70728153802f915454
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-34ef1e24-4066-4bb9-9beb-14e286e03fda
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: e80abfb4cb8d6f7cc379ad9171c43e7db1988c8966d851bf968f6086afe8cf7c
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-54aef02b-6128-434d-8c8d-8d65125b62a2
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: a09ce36bd5ca1e0b53e8a568f29a6a8bca18d4833a597a8fa5e47f5cba5eeb95
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-e06fc4ea-e4b0-4fc9-99b2-b6ca6d1aa168
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: 0f4889b7b5e6d3979932ca8cc40f5fb507df64bd34c8196d9649391be9eec62b
name: python-django-versatileimagefield
arch: src
version: 3.0
epoch: 0
release: 1
url: http://github.com/respondcreate/django-versatileimagefield/
rpm_license: MIT License, see LICENSE
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d1e57b65-bd5c-4206-9935-b0e4ae2902ff
location_href: 00012169-python-django-versatileimagefield/python-django-versatileimagefield-3.0-1.src.rpm
checksum_type: sha256
summary:
  A drop-in replacement for django's ImageField that provides a flexible, intuitive and easily-extensible interface for creating new images from the one assigned to the field.


pkgId: 1abd9a99b28563c675dc0066b25db7978637cb55ae4d1dac9582cfc495d1fa46
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-c78734c2-f40d-4d2a-a19f-09e65ee5836c
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: 83f360d9e15294788bd68727a5185e3efaaa46d52af3a3c763ab0548ad02d7b3
name: python-django-webtest
arch: src
version: 1.9.10
epoch: 0
release: 1
url: https://github.com/django-webtest/django-webtest
rpm_license: MIT license
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4a9928c8-aaa0-4e0a-b56f-43f431a2301d
location_href: 00012322-python-django-webtest/python-django-webtest-1.9.10-1.src.rpm
checksum_type: sha256
summary:
  Instant integration of Ian Bicking's WebTest (http://docs.pylonsproject.org/projects/webtest/) with Django's testing framework.


pkgId: 467ee7a3185c87186c225df10eb0d7c439caefa4e05bf152576ce4a31688d551
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-0450f26c-f6b4-4da4-8f9e-6e0e11039a0a
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: d288a967b96c6b372b61a6ccf4d0893746d7d3c64a6ccbada36f7d9e320b6cb2
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-8c164ab3-9d17-4c95-bdee-2ec43978855a
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: 4e083ac7046c31314d3693f4ec0b8008bce22cc03aecb34189faa83efc8f5a96
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-138cdd62-c69c-4c7c-912a-763f16b6d936
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: 8851e15d667f7960e2cdc36bc5ed86338fa4a849f418b2e44a13ce5450f066f1
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-138cdd62-c69c-4c7c-912a-763f16b6d936
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: f4999e99e4a958cfab19b764696fea7ae5bbb69aa3c41fe1fce8e93ec405fe78
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-bd53c8d2-6cc6-4a92-981a-9b01e8845977
checksum_type: sha256
location_href:
  00011030-python-djangorestframework-camel-case/python-djangorestframework-camel-case-1.4.2-1.src.rpm


pkgId: 465c489382e8bc12cd2b3e6914bad8e48b5d3350bd18fd59cb008b9df1c2433b
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-bd53c8d2-6cc6-4a92-981a-9b01e8845977
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: ce182d1e20a201f13c7252cf3a03182d549344e4a0438204751a68741438aa9b
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-60926072-8e7b-448e-8729-cd1829498e9d
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: adfea146891ed8693cff795a4574e52992b19fd27b5c5953cef9b3753bab9020
name: python-djangorestframework-guardian
arch: src
version: 0.3.0
epoch: 0
release: 1
summary: django-guardian support for Django REST Framework
url: https://github.com/rpkilby/django-rest-framework-guardian
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a06b7e21-3452-4059-ac81-1ecd92416857
location_href: 00014161-python-djangorestframework-guardian/python-djangorestframework-guardian-0.3.0-1.src.rpm
checksum_type: sha256
description:
  [![CircleCI](https://circleci.com/gh/rpkilby/django-rest-framework-guardian.svg?style=shield)](https://circleci.com/gh/rpkilby/django-rest-framework-guardian)
  [![Codecov](https://codecov.io/gh/rpkilby/django-rest-framework-guardian/branch/master/graph/badge.svg)](https://codecov.io/gh/rpkilby/django-rest-framework-guardian)
  [![License](https://img.shields.io/pypi/l/djangorestframework-guardian.svg)](https://pypi.org/project/djangorestframework-guardian)
  [![Version](https://img.shields.io/pypi/v/djangorestframework-guardian.svg)](https://pypi.org/project/djangorestframework-guardian)
  [![Python](https://img.shields.io/pypi/pyversions/djangorestframework-guardian.svg)](https://pypi.org/project/djangorestframework-guardian/)

  django-rest-framework-guardian provides django-guardian integrations for Django REST Framework.
  Currently, this only includes the `ObjectPermissionsFilter`.




  To use django-rest-framework-guardian, install it into your environment.

  ```sh
  $ pip install djangorestframework-guardian
  ```

  Ensure both Django REST Framework and django-guardian are configured and added to your `INSTALLED_APPS` setting.

  ```python
  INSTALLED_APPS = [
      'rest_framework',
      'guardian',
  ]

  AUTHENTICATION_BACKENDS = [
      'django.contrib.auth.backends.ModelBackend',
      'guardian.backends.ObjectPermissionBackend',
  ]
  ```




  The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.

  If you're using `ObjectPermissionsFilter`, you'll probably also want to add an appropriate object permissions
  class, to ensure that users can only operate on instances if they have the appropriate object permissions.  The easiest
  way to do this is to subclass `DjangoObjectPermissions` and add `'view'` permissions to the `perms_map` attribute.

  An example using both `ObjectPermissionsFilter` and `DjangoObjectPermissions` might look like the following:

  **permissions.py**:

  ```python
  from rest_framework import permissions


  class CustomObjectPermissions(permissions.DjangoObjectPermissions):
      """
      Similar to `DjangoObjectPermissions`, but adding 'view' permissions.
      """
      perms_map = {
          'GET': ['s.view_s'],
          'OPTIONS': ['s.view_s'],
          'HEAD': ['s.view_s'],
          'POST': ['s.add_s'],
          'PUT': ['s.change_s'],
          'PATCH': ['s.change_s'],
          'DELETE': ['s.delete_s'],
      }
  ```

  **views.py**:

  ```python
  from rest_framework import viewsets
  from rest_framework_guardian import filters

  from myapp.models import Event
  from myapp.permissions import CustomObjectPermissions
  from myapp.serializers import EventSerializer


  class EventViewSet(viewsets.ModelViewSet):
      """
      Viewset that only lists events if user has 'view' permissions, and only
      allows operations on individual events if user has appropriate 'view', 'add',
      'change' or 'delete' permissions.
      """
      queryset = Event.objects.all()
      serializer_class = EventSerializer
      permission_classes = [CustomObjectPermissions]
      filter_backends = [filters.ObjectPermissionsFilter]
  ```




  A serializer mixin that allows permissions to be easily assigned to users and/or groups.
  So each time an object is created or updated, the `permissions_map` returned by `Serializer.get_permissions_map` will be used to assign permission(s) to that object.

  Please note that the existing permissions will remain intact.

  A usage example might look like the following:

  ```python
  from rest_framework_guardian.serializers import ObjectPermissionsAssignmentMixin

  from blog.models import Post


  class PostSerializer(ObjectPermissionsAssignmentMixin, serializers.ModelSerializer):
      class Meta:
          model = Post
          fields = '__all__'

      def get_permissions_map(self, created):
          current_user = self.context['request'].user
          readers = Group.objects.get(name='readers')
          supervisors = Group.objects.get(name='supervisors')

          return {
              'view_post': [current_user, readers],
              'change_post': [current_user],
              'delete_post': [current_user, supervisors]
          }

  ```




  - Update changelog
  - Update package version in setup.py
  - Create git tag for version
  - Build & upload release to PyPI
    ```bash
    $ pip install -U pip setuptools wheel twine
    $ rm -rf dist/ build/
    $ python setup.py bdist_wheel
    $ twine upload dist/*
    ```



  See: [LICENSE](https://github.com/rpkilby/django-rest-framework-guardian/blob/master/LICENSE)

  BSD 3-Clause License

  Copyright (c) 2018, Ryan P Kilby
  All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright notice, this
    list of conditions and the following disclaimer.

  * Redistributions in binary form must reproduce the above copyright notice,
    this list of conditions and the following disclaimer in the documentation
    and/or other materials provided with the distribution.

  * Neither the name of the copyright holder nor the names of its
    contributors may be used to endorse or promote products derived from
    this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


pkgId: 0b6023e0415ad7fb3357e74554369dd2248ebd8f47643add73923ec03164dc37
name: python-djangorestframework-guardian-help
arch: noarch
version: 0.3.0
epoch: 0
release: 1
summary: Development documents and examples for djangorestframework-guardian
url: https://github.com/rpkilby/django-rest-framework-guardian
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-a06b7e21-3452-4059-ac81-1ecd92416857
rpm_sourcerpm: python-djangorestframework-guardian-0.3.0-1.src.rpm
checksum_type: sha256
description:
  [![CircleCI](https://circleci.com/gh/rpkilby/django-rest-framework-guardian.svg?style=shield)](https://circleci.com/gh/rpkilby/django-rest-framework-guardian)
  [![Codecov](https://codecov.io/gh/rpkilby/django-rest-framework-guardian/branch/master/graph/badge.svg)](https://codecov.io/gh/rpkilby/django-rest-framework-guardian)
  [![License](https://img.shields.io/pypi/l/djangorestframework-guardian.svg)](https://pypi.org/project/djangorestframework-guardian)
  [![Version](https://img.shields.io/pypi/v/djangorestframework-guardian.svg)](https://pypi.org/project/djangorestframework-guardian)
  [![Python](https://img.shields.io/pypi/pyversions/djangorestframework-guardian.svg)](https://pypi.org/project/djangorestframework-guardian/)

  django-rest-framework-guardian provides django-guardian integrations for Django REST Framework.
  Currently, this only includes the `ObjectPermissionsFilter`.




  To use django-rest-framework-guardian, install it into your environment.

  ```sh
  $ pip install djangorestframework-guardian
  ```

  Ensure both Django REST Framework and django-guardian are configured and added to your `INSTALLED_APPS` setting.

  ```python
  INSTALLED_APPS = [
      'rest_framework',
      'guardian',
  ]

  AUTHENTICATION_BACKENDS = [
      'django.contrib.auth.backends.ModelBackend',
      'guardian.backends.ObjectPermissionBackend',
  ]
  ```




  The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.

  If you're using `ObjectPermissionsFilter`, you'll probably also want to add an appropriate object permissions
  class, to ensure that users can only operate on instances if they have the appropriate object permissions.  The easiest
  way to do this is to subclass `DjangoObjectPermissions` and add `'view'` permissions to the `perms_map` attribute.

  An example using both `ObjectPermissionsFilter` and `DjangoObjectPermissions` might look like the following:

  **permissions.py**:

  ```python
  from rest_framework import permissions


  class CustomObjectPermissions(permissions.DjangoObjectPermissions):
      """
      Similar to `DjangoObjectPermissions`, but adding 'view' permissions.
      """
      perms_map = {
          'GET': ['s.view_s'],
          'OPTIONS': ['s.view_s'],
          'HEAD': ['s.view_s'],
          'POST': ['s.add_s'],
          'PUT': ['s.change_s'],
          'PATCH': ['s.change_s'],
          'DELETE': ['s.delete_s'],
      }
  ```

  **views.py**:

  ```python
  from rest_framework import viewsets
  from rest_framework_guardian import filters

  from myapp.models import Event
  from myapp.permissions import CustomObjectPermissions
  from myapp.serializers import EventSerializer


  class EventViewSet(viewsets.ModelViewSet):
      """
      Viewset that only lists events if user has 'view' permissions, and only
      allows operations on individual events if user has appropriate 'view', 'add',
      'change' or 'delete' permissions.
      """
      queryset = Event.objects.all()
      serializer_class = EventSerializer
      permission_classes = [CustomObjectPermissions]
      filter_backends = [filters.ObjectPermissionsFilter]
  ```




  A serializer mixin that allows permissions to be easily assigned to users and/or groups.
  So each time an object is created or updated, the `permissions_map` returned by `Serializer.get_permissions_map` will be used to assign permission(s) to that object.

  Please note that the existing permissions will remain intact.

  A usage example might look like the following:

  ```python
  from rest_framework_guardian.serializers import ObjectPermissionsAssignmentMixin

  from blog.models import Post


  class PostSerializer(ObjectPermissionsAssignmentMixin, serializers.ModelSerializer):
      class Meta:
          model = Post
          fields = '__all__'

      def get_permissions_map(self, created):
          current_user = self.context['request'].user
          readers = Group.objects.get(name='readers')
          supervisors = Group.objects.get(name='supervisors')

          return {
              'view_post': [current_user, readers],
              'change_post': [current_user],
              'delete_post': [current_user, supervisors]
          }

  ```




  - Update changelog
  - Update package version in setup.py
  - Create git tag for version
  - Build & upload release to PyPI
    ```bash
    $ pip install -U pip setuptools wheel twine
    $ rm -rf dist/ build/
    $ python setup.py bdist_wheel
    $ twine upload dist/*
    ```



  See: [LICENSE](https://github.com/rpkilby/django-rest-framework-guardian/blob/master/LICENSE)

  BSD 3-Clause License

  Copyright (c) 2018, Ryan P Kilby
  All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright notice, this
    list of conditions and the following disclaimer.

  * Redistributions in binary form must reproduce the above copyright notice,
    this list of conditions and the following disclaimer in the documentation
    and/or other materials provided with the distribution.

  * Neither the name of the copyright holder nor the names of its
    contributors may be used to endorse or promote products derived from
    this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

location_href:
  00014161-python-djangorestframework-guardian/python-djangorestframework-guardian-help-0.3.0-1.noarch.rpm


pkgId: d01556321d31813a14f54b4f33b6cb3f8d58cade2325e427efe102c155786817
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-94c217b6-4214-4f4a-ae65-6e37959d2a26
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: d6af3cd5b2a1645bf962fda3b92b9b9cceb13334c4b9aa6c5a764def61afb39d
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-5b229784-8fef-4c1b-9057-1e3a6beef9a9
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: dd2e680c572e36f0cbdc1c1a9d7d44f9245abf7a207befc36dca7c1b801c4171
name: python-djangorestframework-recursive-help
arch: noarch
version: 0.1.2
epoch: 0
release: 1
summary: Development documents and examples for djangorestframework-recursive
url: https://github.com/heywbj/django-rest-framework-recursive
rpm_license: BSD
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f78dec55-3fae-4b73-b519-4a60e93ff0e3
rpm_sourcerpm: python-djangorestframework-recursive-0.1.2-1.src.rpm
checksum_type: sha256
location_href:
  00012856-python-djangorestframework-recursive/python-djangorestframework-recursive-help-0.1.2-1.noarch.rpm


pkgId: d539a373df719adef7e02bc289af9401df339765557b05ce8208098e2605f5e3
name: python-djangorestframework-stubs
arch: src
version: 1.10.0
epoch: 0
release: 1
summary: PEP-484 stubs for django-rest-framework
url: https://github.com/typeddjango/djangorestframework-stubs
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5b2f42c7-c489-4c90-8cb6-a63caefdc168
location_href: 00010934-python-djangorestframework-stubs/python-djangorestframework-stubs-1.10.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://travis-ci.com/typeddjango/djangorestframework-stubs.svg?branch=master)](https://travis-ci.com/typeddjango/djangorestframework-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)


  Mypy stubs for [Django REST Framework](https://pypi.org/project/djangorestframework/).
  Supports Python 3.7 and up.



  ```bash
  pip install djangorestframework-stubs[compatible-mypy]
  ```

  To make mypy aware of the plugin, you need to add

  ```ini
  [mypy]
  plugins =
      mypy_drf_plugin.main
  ```

  in your `mypy.ini` file.




  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

  You can always also reach out in gitter to discuss your contributions!


pkgId: a1c023f2c240822e2424f68af115c0736b0ffd2b9ea5a02c212fcf95922b42d5
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-be107584-7542-48a7-888e-8f9c4d3bb8b3
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: 74d2abf20834a7b77e5ecee687d2659e05b19ee4c74e2623237c079f7e3df91f
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-fde56863-c9a5-4577-9748-511fb8a2287d
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: c11032825e4afa19c06394f75dcd429120c049a0b45a5a6c118ae44d69ea2bb4
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-9b12e1b1-645c-4710-9342-470424f3da3a
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: c8fd63b7e16d652ccfdb25aa657dc19159644781b89a22ae9f42f3de94470549
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-98e2bdb5-7705-44bf-b02c-f6ddcd8e3864
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: 78a626c92e8c56a64084d56a910024044f2f9a1b94c4ec27d4c7af71789ab6ca
name: python-djrill
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: Mandrill transactional email for Django
url: https://github.com/brack3t/Djrill/
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-807037f3-0d17-421a-b4b2-9220c164852e
location_href: 00013770-python-djrill/python-djrill-2.1.0-1.src.rpm
checksum_type: sha256
description:
      * Github: project page, exactly as it appears here
      * Docs: shared-intro section gets included in docs/index.rst
              quickstart section gets included in docs/quickstart.rst
      * PyPI: project page (via setup.py long_description),
              with several edits to freeze it to the specific PyPI release
              (see long_description_from_readme in setup.py)
      You can use docutils 1.0 markup, but *not* any Sphinx additions.
  Djrill integrates the `Mandrill <http://mandrill.com>`_ transactional
  email service into Django.
    **PROJECT STATUS: INACTIVE**
    As of April, 2016, Djrill is no longer actively maintained (other
    than security updates). It is likely to keep working unless/until
    Mandrill changes their APIs, but Djrill will not be updated for
    newer Django versions or Mandrill changes.
    (`more info <https://github.com/brack3t/Djrill/issues/111>`_)
    You may be interested in
    `django-anymail <https://github.com/anymail/django-anymail>`_,
    a Djrill fork that supports Mailgun, Postmark, SendGrid, and other
    transactional ESPs (including limited support for Mandrill).
  In general, Djrill "just works" with Django's built-in `django.core.mail`
  package. It includes:
  * Support for HTML, attachments, extra headers, and other features of
    `Django's built-in email <https://docs.djangoproject.com/en/stable/topics/email/>`_
  * Mandrill-specific extensions like tags, metadata, tracking, and MailChimp templates
  * Optional support for Mandrill inbound email and other webhook notifications,
    via Django signals
  Djrill is released under the BSD license. It is tested against Django 1.4--1.9
  (including Python 3 with Django 1.6+, and PyPy support with Django 1.5+).
  Djrill uses `semantic versioning <http://semver.org/>`_.
  **Resources**
  * Full documentation: https://djrill.readthedocs.org/en/v2.1/
  * Package on PyPI: https://pypi.python.org/pypi/djrill
  * Project on Github: https://github.com/brack3t/Djrill


pkgId: 1acb6c4736cbef7eb66b8b6e83bd221b9a3049fb2c8db1d38ee4e90cd906c2db
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-4352ccd5-5aec-4f26-ae47-33fdfde8e342
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: 26ce8d9d0b005fc2830c1380db306d0aa8bb2cf0c235c5635f60a867cff7e5b5
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-1944761e-0bb0-4e3f-afa7-14bf0bc8d35f
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: bd8d22380d3c866ba166e13a9c71842ca388442db6f6abeb4ce79c060ef45555
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-d3b2f2d0-e8e6-4088-916e-ee24b05f8a6e
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: 4a248aba0bce85f772c5a9f1b1c20b93c5932b1c230ce92f26a0a04f0ffa4374
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-02e75a01-4815-4d98-a114-e99d40cc6c6a
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: 5740fa3850c2bdede22730e3109d9a3c82944a3ecd779cbe1ee3914dcc08fb1e
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-6bab1986-cb32-48f5-92c9-a6b4619d63d9
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: c0e2938cb26f2fd9507f63808be167dd029d1fa77977ca78f2b833c5fb451bb1
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-5bc2efac-5ef5-45dc-b18b-e539e5b3b6a7
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: 02ac63436f4929d00bcb4a9770d0577004c8b4db069134d6818039eec472fad4
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-adc3de19-19d0-448a-8e4a-b9e6e34cb19e
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: 8640934cd10a7197a631f49dcbb7313ec13ea0d00b05f0a6048fda2995718e9b
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-f18ff7da-e28f-4b83-9d08-d90bfc0209ed
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: 6d07859295527b2e6e25dbdd6a52e48ec4c6794dc1229de4658757921cf94225
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-30f3b365-dba1-48d6-9327-f81b2a15c43f
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: 0f8f81855280adabc8b3995acad4744c37844e954b2c9a18380accbc49d089c0
name: python-docopt
arch: src
version: 0.6.2
epoch: 0
release: 1
summary: Pythonic argument parser, that will make you smile
url: http://docopt.org
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-d5e661d3-5d76-4ea1-aa89-d4b292acf9cf
location_href: 00009110-python-docopt/python-docopt-0.6.2-1.src.rpm
checksum_type: sha256
description:
  Video introduction to **docopt**: `PyCon UK 2012: Create *beautiful*
  command-line interfaces with Python <http://youtu.be/pXhcPJK5cMc>`_
      New in version 0.6.1:
      - Fix issue `#85 <https://github.com/docopt/docopt/issues/85>`_
        which caused improper handling of ``[options]`` shortcut
        if it was present several times.
      New in version 0.6.0:
      - New argument ``options_first``, disallows interspersing options
        and arguments.  If you supply ``options_first=True`` to
        ``docopt``, it will interpret all arguments as positional
        arguments after first positional argument.
      - If option with argument could be repeated, its default value
        will be interpreted as space-separated list. E.g. with
        ``[default: ./here ./there]`` will be interpreted as
        ``['./here', './there']``.
      Breaking changes:
      - Meaning of ``[options]`` shortcut slightly changed. Previously
        it ment *"any known option"*. Now it means *"any option not in
        usage-pattern"*.  This avoids the situation when an option is
        allowed to be repeated unintentionaly.
      - ``argv`` is ``None`` by default, not ``sys.argv[1:]``.
        This allows ``docopt`` to always use the *latest* ``sys.argv``,
        not ``sys.argv`` during import time.
  Isn't it awesome how ``optparse`` and ``argparse`` generate help
  messages based on your code?!
  *Hell no!*  You know what's awesome?  It's when the option parser *is*
  generated based on the beautiful help message that you write yourself!
  This way you don't need to write this stupid repeatable parser-code,
  and instead can write only the help message--*the way you want it*.
  **docopt** helps you create most beautiful command-line interfaces
  *easily*:
      """Naval Fate.
      Usage:
        naval_fate.py ship new <name>...
        naval_fate.py ship <name> move <x> <y> [--speed=<kn>]
        naval_fate.py ship shoot <x> <y>
        naval_fate.py mine (set|remove) <x> <y> [--moored | --drifting]
        naval_fate.py (-h | --help)
        naval_fate.py --version
      Options:
        -h --help     Show this screen.
        --version     Show version.
        --speed=<kn>  Speed in knots [default: 10].
        --moored      Moored (anchored) mine.
        --drifting    Drifting mine.
      """
      from docopt import docopt
      if __name__ == '__main__':
          arguments = docopt(__doc__, version='Naval Fate 2.0')
          print(arguments)
  Beat that! The option parser is generated based on the docstring above
  that is passed to ``docopt`` function.  ``docopt`` parses the usage
  pattern (``"Usage: ..."``) and option descriptions (lines starting
  with dash "``-``") and ensures that the program invocation matches the
  usage pattern; it parses options, arguments and commands based on
  that. The basic idea is that *a good help message has all necessary
  information in it to make a parser*.
  Also, `PEP 257 <http://www.python.org/dev/peps/pep-0257/>`_ recommends
  putting help message in the module docstrings.


pkgId: a3080bebdfd247eb76f8b4f0d10f0883a3f3ef156990e8c5bc1303691040951f
name: python-docplex
arch: src
version: 2.25.236
epoch: 0
release: 1
summary: The IBM Decision Optimization CPLEX Modeling for Python
url: https://www.ibm.com/cloud/decision-optimization-for-watson-studio
rpm_license: Apache 2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-72632b92-a5b6-4d4f-a8ab-da17d76126a4
location_href: 00012331-python-docplex/python-docplex-2.25.236-1.src.rpm
checksum_type: sha256
description:
  Welcome to the IBM Decision Optimization CPLEX Modeling for Python.
  Licensed under the Apache License v2.0.
  With this library, you can quickly and easily add the power of optimization to
  your application. You need IBM ILOG CPLEX Optimization Studio to solve the models.
  This library is composed of 2 modules:
      * IBM Decision Optimization CPLEX Optimizer Modeling for Python - with namespace docplex.mp
      * IBM Decision Optimization CP Optimizer Modeling for Python - with namespace docplex.cp
  Solving with CPLEX locally requires that IBM ILOG CPLEX Optimization Studio V12.8 or later
  is installed on your machine.
  This library is `numpy` friendly.
  `Documentation <http://ibmdecisionoptimization.github.io/docplex-doc/>`_
  `Examples <https://github.com/IBMDecisionOptimization/docplex-examples>`_


pkgId: 1d9cb1dd26c89bd3e169a447c9ba3152ef8fe7003f1e736a9448098c7194cfc3
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-a47dd5c7-387a-4373-9336-9859ff02e21f
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: cb344c2de50ccc95182597b01849dc53ff1b327df1f8d57c4edfb27679513c99
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-5816f25f-bcd5-4214-addc-92ce846aac44
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: 420fa1e709a6a037bfce68f21541067e411b7e1a7b6ba7f94f373c522f24a009
name: python-docxcompose
arch: src
version: 1.4.0
epoch: 0
release: 1
summary: Compose .docx documents
url: https://github.com/4teamwork/docxcompose
rpm_license: MIT license
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4800a2f4-5e80-4f1d-87fe-698c46c17e4e
location_href: 00013807-python-docxcompose/python-docxcompose-1.4.0-1.src.rpm
checksum_type: sha256
description:
  Append a document to another document:
      from docxcompose.composer import Composer
      from docx import Document
      master = Document("master.docx")
      composer = Composer(master)
      doc1 = Document("doc1.docx")
      composer.append(doc1)
      composer.save("combined.docx")


pkgId: 039b9ac8b99319a244f3e58487dad014402ae91e4bb2dae6abea39f0b3e3b69d
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-27b96b45-09a6-44ec-9fee-34d50770e924
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: 7e7621caaca8396c421731c078704e5c393ae251545ebe69c7752c9ead365dd4
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-8d76fe8b-2f2f-44f2-87bd-9b5e5d9275eb
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: 66cda193f7e748f248defee6138caf7ecc275ec9fc128b1924688c2bd55d5d26
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-d7594d60-c4d9-4c54-96a4-da34299f9c86
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: b9453a19c7083ef0a6282424d64351d414f548aea64ae5258ab23fa59862d16f
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-c215feef-a2fd-40cb-af59-17eaff3f60c7
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: 221f0eb813fb61e30803fc1ec5883cf1fc5e1552ce857cd5ce3d7e2edf101278
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-93c2d07b-bef3-46d1-b349-464f788050f5
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: 920844877e16587365d8b6e5e5013bf340cbebbd20de8c986eb92094c59ac389
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-fd703c4b-dfd5-47cf-a33b-c79c4a638ab0
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: fa2476cf4dc7cb14c05bbc77fbdf046e8d596e8c4f30f9788dc824f518035912
name: python-dragonfly-energy
arch: src
version: 1.22.114
epoch: 0
release: 1
summary: Dragonfly extension for energy simulation.
url: https://github.com/ladybug-tools/dragonfly-energy
rpm_license: AGPL-3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-8cfd552b-99da-4606-89c7-2d176d64a318
location_href: 00013278-python-dragonfly-energy/python-dragonfly-energy-1.22.114-1.src.rpm
checksum_type: sha256
description:
  ![Dragonfly](https://www.ladybug.tools/assets/img/dragonfly.png)

  [![Build Status](https://github.com/ladybug-tools/dragonfly-energy/workflows/CI/badge.svg)](https://github.com/ladybug-tools/dragonfly-energy/actions)
  [![Coverage Status](https://coveralls.io/repos/github/ladybug-tools/dragonfly-energy/badge.svg?branch=master)](https://coveralls.io/github/ladybug-tools/dragonfly-energy)

  [![Python 3.7](https://img.shields.io/badge/python-3.7-blue.svg)](https://www.python.org/downloads/release/python-370/) [![Python 2.7](https://img.shields.io/badge/python-2.7-green.svg)](https://www.python.org/downloads/release/python-270/) [![IronPython](https://img.shields.io/badge/ironpython-2.7-red.svg)](https://github.com/IronLanguages/ironpython2/releases/tag/ipy-2.7.8/)



  Dragonfly extension for energy simulation.



  `pip install dragonfly-energy`



  ```python
  import dragonfly_energy
  ```




  Since the building geometry in dragonfly is fundamentally 2D, creating a model of
  a building and assigning energy model properties can be done with a few lines of
  code. Here is an example:

  ```python
  from dragonfly.model import Model
  from dragonfly.building import Building
  from dragonfly.story import Story
  from dragonfly.room2d import Room2D
  from dragonfly.windowparameter import SimpleWindowRatio
  from honeybee_energy.lib.programtypes import office_program


  pts_1 = (Point3D(0, 0, 3), Point3D(0, 10, 3), Point3D(10, 10, 3), Point3D(10, 0, 3))
  pts_2 = (Point3D(10, 0, 3), Point3D(10, 10, 3), Point3D(20, 10, 3), Point3D(20, 0, 3))
  pts_3 = (Point3D(0, 10, 3), Point3D(0, 20, 3), Point3D(10, 20, 3), Point3D(10, 10, 3))
  pts_4 = (Point3D(10, 10, 3), Point3D(10, 20, 3), Point3D(20, 20, 3), Point3D(20, 10, 3))
  room2d_1 = Room2D('Office1', Face3D(pts_1), 3)
  room2d_2 = Room2D('Office2', Face3D(pts_2), 3)
  room2d_3 = Room2D('Office3', Face3D(pts_3), 3)
  room2d_4 = Room2D('Office4', Face3D(pts_4), 3)
  story = Story('OfficeFloor', [room2d_1, room2d_2, room2d_3, room2d_4])
  story.solve_room_2d_adjacency(0.01)
  story.set_outdoor_window_parameters(SimpleWindowRatio(0.4))
  story.multiplier = 4
  building = Building('OfficeBuilding', [story])


  for room in story.room_2ds:
      room.properties.energy.program_type = office_program
      room.properties.energy.add_default_ideal_air()


  model = Model('NewDevelopment', [building])
  ```

  Once a Dragonfly Model has been created, it can be converted to a honeybee Model,
  which can then be converted to IDF format like so:

  ```python

  model = Model('NewDevelopment', [building])


  hb_models = model.to_honeybee('Building', use_multiplier=False, tolerance=0.01)
  idfs = [hb_model.to.idf(hb_model) for hb_model in hb_models]
  ```

  The dragonfly model can also be serialized to a geoJSON to be simulated with URBANopt.

  ```python
  from ladybug.location import Location


  model = Model('NewDevelopment', [building])


  location = Location('Boston', 'MA', 'USA', 42.366151, -71.019357)
  sim_folder = './tests/urbanopt_model'
  geojson, hb_model_jsons, hb_models = model.to.urbanopt(model, location, folder=sim_folder)
  ```



  1. Clone this repo locally
  ```
  git clone git@github.com:ladybug-tools/dragonfly-energy



  git clone https://github.com/ladybug-tools/dragonfly-energy
  ```
  2. Install dependencies:
  ```
  cd dragonfly-energy
  pip install -r dev-requirements.txt
  pip install -r requirements.txt
  ```

  3. Run Tests:
  ```
  python -m pytest tests/
  ```

  4. Generate Documentation:
  ```
  sphinx-apidoc -f -e -d 4 -o ./docs ./dragonfly_energy
  sphinx-build -b html ./docs ./docs/_build/docs
  ```


pkgId: badcc777f94ab43b5fc69d68b09dc923fe47cc8ea8add55c869c1ce380b76384
name: python-dramatiq
arch: src
version: 1.14.2
epoch: 0
release: 1
summary: Background Processing for Python 3.
url: https://pypi.org/project/dramatiq/
rpm_license: GNU Lesser General Public License v3 or later (LGPLv3+)
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-1cda68e0-ee94-4ba6-a8e4-ed581fa63a4f
location_href: 00012593-python-dramatiq/python-dramatiq-1.14.2-1.src.rpm
checksum_type: sha256
description:
  <img src="https://dramatiq.io/_static/logo.png" align="right" width="131" />



  [![Build Status](https://github.com/Bogdanp/dramatiq/workflows/CI/badge.svg)](https://github.com/Bogdanp/dramatiq/actions?query=workflow%3A%22CI%22)
  [![PyPI version](https://badge.fury.io/py/dramatiq.svg)](https://badge.fury.io/py/dramatiq)
  [![Documentation](https://img.shields.io/badge/doc-latest-brightgreen.svg)](http://dramatiq.io)
  [![Discuss](https://img.shields.io/badge/discuss-online-orange.svg)](https://groups.io/g/dramatiq-users)

  *A fast and reliable distributed task processing library for Python 3.*

  <hr/>

  **Changelog**: https://dramatiq.io/changelog.html <br/>
  **Community**: https://groups.io/g/dramatiq-users <br/>
  **Documentation**: https://dramatiq.io <br/>

  <hr/>

  <h3 align="center">Sponsors</h3>

  <p align="center">
    <a href="https://franz.defn.io" target="_blank">
      <img width="64px" src="docs/source/_static/franz-logo.png">
      <br/>
      Franz: macOS Kafka Client
    </a>
    <br/>
    <br/>
    <a href="https://www.sendcloud.com/jobs/?utm_source=dramatiq.io&utm_medium=Banner&utm_campaign=Sponsored%20Banner&utm_content=V1" target="_blank">
      <img width="222px" src="docs/source/_static/sendcloud-logo.png">
    </a>
  </p>




  If you want to use it with [RabbitMQ]

      pip install 'dramatiq[rabbitmq, watch]'

  or if you want to use it with [Redis]

      pip install 'dramatiq[redis, watch]'




  Make sure you've got [RabbitMQ] running, then create a new file called
  `example.py`:

  ``` python
  import dramatiq
  import requests
  import sys


  @dramatiq.actor
  def count_words(url):
      response = requests.get(url)
      count = len(response.text.split(" "))
      print(f"There are {count} words at {url!r}.")


  if __name__ == "__main__":
      count_words.send(sys.argv[1])
  ```

  In one terminal, run your workers:

      dramatiq example

  In another, start enqueueing messages:

      python example.py http://example.com
      python example.py https://github.com
      python example.py https://news.ycombinator.com

  Check out the [user guide] to learn more!




  dramatiq is licensed under the LGPL.  Please see [COPYING] and
  [COPYING.LESSER] for licensing details.


  [COPYING.LESSER]: https://github.com/Bogdanp/dramatiq/blob/master/COPYING.LESSER
  [COPYING]: https://github.com/Bogdanp/dramatiq/blob/master/COPYING
  [RabbitMQ]: https://www.rabbitmq.com/
  [Redis]: https://redis.io
  [user guide]: https://dramatiq.io/guide.html


pkgId: f3bb1f17f13fefacf8f54d3f6e34654b849e9c407f4fa40ff2daa25cef2cc5b7
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-1a3eaa57-abdf-41aa-9f8f-2362eedcdc4f
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: 12284ef704a19282875155773b02c6fdbcc2d3d04146203b56b4860c7a9176a6
name: python-drf-extra-fields
arch: src
version: 3.4.1
epoch: 0
release: 1
summary: Additional fields for Django Rest Framework.
url: https://github.com/Hipo/drf-extra-fields
rpm_license: Apache-2.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-8b94c850-ff13-4df8-8a82-d1c23ba023b5
location_href: 00013448-python-drf-extra-fields/python-drf-extra-fields-3.4.1-1.src.rpm
checksum_type: sha256
description:
  Extra Fields for Django Rest Framework
  [![Build Status](https://github.com/Hipo/drf-extra-fields/actions/workflows/tests.yml/badge.svg?branch=master)](https://github.com/Hipo/drf-extra-fields/actions)
  [![codecov](https://codecov.io/gh/Hipo/drf-extra-fields/branch/master/graph/badge.svg)](https://codecov.io/gh/Hipo/drf-extra-fields)
  [![PyPI Version](https://img.shields.io/pypi/v/drf-extra-fields.svg)](https://pypi.org/project/drf-extra-fields)
  [![Python Versions](https://img.shields.io/pypi/pyversions/drf-extra-fields.svg)](https://pypi.org/project/drf-extra-fields)


pkgId: 30df15653303ec561638e5977a5090814191a9221d838ba54c291c0a5460b2a8
name: python-drf-flex-fields
arch: src
version: 1.0.2
epoch: 0
release: 1
summary: Flexible, dynamic fields and nested resources for Django REST Framework serializers.
url: https://github.com/rsinger86/drf-flex-fields
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-0e88bb94-7fb8-49c5-8fe0-8d864e8caa40
location_href: 00013437-python-drf-flex-fields/python-drf-flex-fields-1.0.2-1.src.rpm
checksum_type: sha256
description:
  [![Package version](https://badge.fury.io/py/drf-flex-fields.svg)](https://pypi.python.org/pypi/drf-flex-fields)
  [![Python versions](https://img.shields.io/pypi/status/drf-flex-fields.svg)](https://img.shields.io/pypi/status/django-lifecycle.svg/)

  Flexible, dynamic fields and nested models for Django REST Framework serializers.



  FlexFields (DRF-FF) for [Django REST Framework](https://django-rest-framework.org) is a package designed to provide a common baseline of functionality for dynamically setting fields and nested models within DRF serializers. This package is designed for simplicity, with minimal magic and entanglement with DRF's foundational classes.

  Key benefits:

  - Easily set up fields that be expanded to their fully serialized counterparts via query parameters (`users/?expand=organization,friends`)
  - Select a subset of fields by either:
    - specifying which ones should be included (`users/?fields=id,first_name`)
    - specifying which ones should be excluded (`users/?omit=id,first_name`)
  - Use dot notation to dynamically modify fields at arbitrary depths (`users/?expand=organization.owner.roles`)
  - Flexible API - options can also be passed directly to a serializer: `UserSerializer(obj, expand=['organization'])`



  ```python
  from rest_flex_fields import FlexFieldsModelSerializer

  class StateSerializer(FlexFieldsModelSerializer):
      class Meta:
          model = State
          fields = ('id', 'name')

  class CountrySerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ('id', 'name', 'population', 'states')
          expandable_fields = {
            'states': (StateSerializer, {'many': True})
          }

  class PersonSerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Person
          fields = ('id', 'name', 'country', 'occupation')
          expandable_fields = {'country': CountrySerializer}
  ```

  ```
  GET /people/142/
  ```

  ```json
  {
    "id": 142,
    "name": "Jim Halpert",
    "country": 1
  }
  ```

  ```
  GET /people/142/?expand=country.states
  ```

  ```json
  {
    "id": 142,
    "name": "Jim Halpert",
    "country": {
      "id": 1,
      "name": "United States",
      "states": [
        {
          "id": 23,
          "name": "Ohio"
        },
        {
          "id": 2,
          "name": "Pennsylvania"
        }
      ]
    }
  }
  ```



  - [Django REST - FlexFields](#django-rest---flexfields)
  - [Overview](#overview)
  - [Quick Start](#quick-start)
  - [Table of Contents:](#table-of-contents)
  - [Setup](#setup)
  - [Usage](#usage)
    - [Dynamic Field Expansion](#dynamic-field-expansion)
    - [Deferred Fields](#deferred-fields)
    - [Deep, Nested Expansion](#deep-nested-expansion)
    - [Field Expansion on "List" Views <a id="list-views"></a>](#field-expansion-on-list-views-)
    - [Expanding a "Many" Relationship <a id="expanding-many"></a>](#expanding-a-many-relationship-)
    - [Dynamically Setting Fields (Sparse Fields) <a id="dynamically-setting-fields"></a>](#dynamically-setting-fields-sparse-fields-)
    - [Reference serializer as a string (lazy evaluation) <a id="lazy-ref"></a>](#reference-serializer-as-a-string-lazy-evaluation-)
    - [Increased re-usability of serializers <a id="increased-reuse"></a>](#increased-re-usability-of-serializers-)
  - [Serializer Options](#serializer-options)
  - [Advanced](#advanced)
    - [Customization](#customization)
    - [Serializer Introspection](#serializer-introspection)
    - [Use Wildcards to Match Multiple Fields](#wildcards)
    - [Combining Sparse Fields and Field Expansion <a id="combining-sparse-and-expanded"></a>](#combining-sparse-fields-and-field-expansion-)
    - [Utility Functions <a id="utils"></a>](#utility-functions-)
      - [rest_flex_fields.is_expanded(request, field: str)](#rest_flex_fieldsis_expandedrequest-field-str)
      - [rest_flex_fields.is_included(request, field: str)](#rest_flex_fieldsis_includedrequest-field-str)
    - [Query optimization (experimental)](#query-optimization-experimental)
  - [Changelog <a id="changelog"></a>](#changelog-)
  - [Testing](#testing)
  - [License](#license)



  First install:

  ```
  pip install drf-flex-fields
  ```

  Then have your serializers subclass `FlexFieldsModelSerializer`:

  ```python
  from rest_flex_fields import FlexFieldsModelSerializer

  class StateSerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ('id', 'name')

  class CountrySerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ('id', 'name', 'population', 'states')
          expandable_fields = {
            'states': (StateSerializer, {'many': True})
          }
  ```

  Alternatively, you can add the `FlexFieldsSerializerMixin` mixin to a model serializer.





  To define expandable fields, add an `expandable_fields` dictionary to your serializer's `Meta` class. Key the dictionary with the name of the field that you want to dynamically expand, and set its value to either the expanded serializer or a tuple where the first element is the serializer and the second is a dictionary of options that will be used to instantiate the serializer.

  ```python
  class CountrySerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ['name', 'population']


  class PersonSerializer(FlexFieldsModelSerializer):
      country = serializers.PrimaryKeyRelatedField(read_only=True)

      class Meta:
          model = Person
          fields = ['id', 'name', 'country', 'occupation']

          expandable_fields = {
              'country': CountrySerializer
          }
  ```

  If the default serialized response is the following:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "country": 12,
    "occupation": "Programmer"
  }
  ```

  When you do a `GET /person/13322?expand=country`, the response will change to:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "country": {
      "name": "United States",
      "population": 330000000
    },
    "occupation": "Programmer"
  }
  ```



  Alternatively, you could treat `country` as a "deferred" field by not defining it among the default fields. To make a field deferred, only define it within the serializer's `expandable_fields`.



  Let's say you add `StateSerializer` as a serializer nested inside the country serializer above:

  ```python
  class StateSerializer(FlexFieldsModelSerializer):
      class Meta:
          model = State
          fields = ['name', 'population']


  class CountrySerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ['name', 'population']

          expandable_fields = {
              'states': (StateSerializer, {'many': True})
          }

  class PersonSerializer(FlexFieldsModelSerializer):
      country = serializers.PrimaryKeyRelatedField(read_only=True)

      class Meta:
          model = Person
          fields = ['id', 'name', 'country', 'occupation']

          expandable_fields = {
              'country': CountrySerializer
          }
  ```

  Your default serialized response might be the following for `person` and `country`, respectively:

  ```json
  {
    "id" : 13322,
    "name" : "John Doe",
    "country" : 12,
    "occupation" : "Programmer",
  }

  {
    "id" : 12,
    "name" : "United States",
    "states" : "http://www.api.com/countries/12/states"
  }
  ```

  But if you do a `GET /person/13322?expand=country.states`, it would be:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "occupation": "Programmer",
    "country": {
      "id": 12,
      "name": "United States",
      "states": [
        {
          "name": "Ohio",
          "population": 11000000
        }
      ]
    }
  }
  ```

  Please be kind to your database, as this could incur many additional queries. Though, you can mitigate this impact through judicious use of `prefetch_related` and `select_related` when defining the queryset for your viewset.



  If you request many objects, expanding fields could lead to many additional database queries. Subclass `FlexFieldsModelViewSet` if you want to prevent expanding fields by default when calling a ViewSet's `list` method. Place those fields that you would like to expand in a `permit_list_expands` property on the ViewSet:

  ```python
  from rest_flex_fields import is_expanded

  class PersonViewSet(FlexFieldsModelViewSet):
      permit_list_expands = ['employer']
      serializer_class = PersonSerializer

      def get_queryset(self):
          queryset = models.Person.objects.all()
          if is_expanded(self.request, 'employer'):
              queryset = queryset.select_related('employer')
          return queryset
  ```

  Notice how this example is using the `is_expanded` utility method as well as `select_related` and `prefetch_related` to efficiently query the database if the field is expanded.



  Set `many` to `True` in the serializer options to make sure "to many" fields are expanded correctly.

  ```python
  class StateSerializer(FlexFieldsModelSerializer):
      class Meta:
          model = State
          fields = ['name', 'population']


  class CountrySerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ['name', 'population']

          expandable_fields = {
              'states': (StateSerializer, {'many': True})
          }
  ```

  A request to `GET /countries?expand=states` will return:

  ```python
  {
      "id" : 12,
      "name" : "United States",
      "states" : [
        {
          "name" : "Alabama",
          "population": 11000000
        },
        //... more states ... //
        {
          "name" : "Ohio",
          "population": 11000000
        }
      ]
  }
  ```



  You can use either the `fields` or `omit` keywords to declare only the fields you want to include or to specify fields that should be excluded.

  Consider this as a default serialized response:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "country": {
      "name": "United States",
      "population": 330000000
    },
    "occupation": "Programmer",
    "hobbies": ["rock climbing", "sipping coffee"]
  }
  ```

  To whittle down the fields via URL parameters, simply add `?fields=id,name,country` to your requests to get back:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "country": {
      "name": "United States",
      "population": 330000000
    }
  }
  ```

  Or, for more specificity, you can use dot-notation, `?fields=id,name,country.name`:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "country": {
      "name": "United States"
    }
  }
  ```

  Or, if you want to leave out the nested country object, do `?omit=country`:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "occupation": "Programmer",
    "hobbies": ["rock climbing", "sipping coffee"]
  }
  ```



  To avoid circular import problems, it's possible to lazily evaluate a string reference to you serializer class using this syntax:

  ```python
  expandable_fields = {
      'record_set': ('<module_path_to_serializer_class>.RelatedSerializer', {'many': True})
  }
  ```

  **Note**:
  Prior to version `0.9.0`, it was assumed your serializer classes would be in a module with the following path:
  `<app_name>.serializers`.

  This import style will still work, but you can also now specify fully-qualified import paths to any locations.



  The `omit` and `fields` options can be passed directly to serializers. Rather than defining a separate, slimmer version of a regular serializer, you can re-use the same serializer and declare which fields you want.

  ```python
  from rest_flex_fields import FlexFieldsModelSerializer

  class CountrySerializer(FlexFieldsModelSerializer):
      class Meta:
          model = Country
          fields = ['id', 'name', 'population', 'capital', 'square_miles']

  class PersonSerializer(FlexFieldsModelSerializer):
      country = CountrySerializer(fields=['id', 'name'])

      class Meta:
          model = Person
          fields = ['id', 'name', 'country']


  serializer = PersonSerializer(person)
  print(serializer.data)

  >>>{
    "id": 13322,
    "name": "John Doe",
    "country": {
      "id": 1,
      "name": "United States",
    }
  }
  ```



  Dynamic field options can be passed in the following ways:

  - from the request's query parameters; separate multiple values with a commma
  - as keyword arguments directly to the serializer class when its constructed
  - from a dictionary placed as the second element in a tuple when defining `expandable_fields`

  Approach #1

  ```
  GET /people?expand=friends.hobbies,employer&omit=age
  ```

  Approach #2

  ```python
  serializer = PersonSerializer(
    person,
    expand=["friends.hobbies", "employer"],
    omit="friends.age"
  )
  ```

  Approach #3

  ```python

  class PersonSerializer(FlexFieldsModelSerializer):
    // Your field definitions

    class Meta:
      model = Person
      fields = ["age", "hobbies", "name"]
      expandable_fields = {
        'friends': (
          'serializer.FriendSerializer',
          {'many': True, "expand": ["hobbies"], "omit": ["age"]}
        )
      }
  ```

  | Option |                                 Description                                  |
  | ------ | :--------------------------------------------------------------------------: |
  | expand | Fields to expand; must be configured in the serializer's `expandable_fields` |
  | fields |         Fields that should be included; all others will be excluded          |
  | omit   |         Fields that should be excluded; all others will be included          |





  Parameter names and wildcard values can be configured within a Django setting, named `REST_FLEX_FIELDS`.

  | Option                        |                                                                                                                                                                                                                                                                         Description                                                                                                                                                                                                                                                                          | Default         |
  |-------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|-----------------|
  | EXPAND_PARAM                  |                                                                                                                                                                                                                                                   The name of the parameter with the fields to be expanded                                                                                                                                                                                                                                                   | `"expand"`      |
  | MAXIMUM_EXPANSION_DEPTH       |                                                                                                                                                                                                                                                      The max allowed expansion depth. By default it's unlimited. Expanding `state.towns` would equal a depth of 2                                                                                                                                                                                                                                            | `None`          |
  | FIELDS_PARAM                  |                                                                                                                                                                                                                                      The name of the parameter with the fields to be included (others will be omitted)                                                                                                                                                                                                                                       | `"fields"`      |
  | OMIT_PARAM                    |                                                                                                                                                                                                                                                   The name of the parameter with the fields to be omitted                                                                                                                                                                                                                                                    | `"omit"`        |
  | RECURSIVE_EXPANSION_PERMITTED |                                                                                                                                                                                                                                             If `False`, an exception is raised when a recursive pattern is found                                                                                                                                                                                                                                             | `True`          |
  | WILDCARD_VALUES               | List of values that stand in for all field names. Can be used with the `fields` and `expand` parameters. <br><br>When used with `expand`, a wildcard value will trigger the expansion of all `expandable_fields` at a given level.<br><br>When used with `fields`, all fields are included at a given level. For example, you could pass `fields=name,state.*` if you have a city resource with a nested state in order to expand only the city's name field and all of the state's fields. <br><br>To disable use of wildcards, set this setting to `None`. | `["*", "~all"]` |

  For example, if you want your API to work a bit more like [JSON API](https://jsonapi.org/format/#fetching-includes), you could do:

  ```python
  REST_FLEX_FIELDS = {"EXPAND_PARAM": "include"}
  ```



  A `maximum_expansion_depth` integer property can be set on a serializer class.

  `recursive_expansion_permitted` boolean property can be set on a serializer class.

  Both settings raise `serializers.ValidationError` when conditions are met but exceptions can be customized by overriding the `recursive_expansion_not_permitted` and `expansion_depth_exceeded` methods.




  When using an instance of `FlexFieldsModelSerializer`, you can examine the property `expanded_fields` to discover which fields, if any, have been dynamically expanded.



  You can pass `expand=*` ([or another value of your choosing](#customization)) to automatically expand all fields that are available for expansion at a given level. To refer to nested resources, you can use dot-notation. For example, requesting `expand=menu.sections` for a restaurant resource would expand its nested `menu` resource, as well as that menu's nested `sections` resource.

  Or, when requesting sparse fields, you can pass `fields=*` to include only the specified fields at a given level. To refer to nested resources, you can use dot-notation. For example, if you have an `order` resource, you could request all of its fields as well as only two fields on its nested `restaurant` resource with the following: `fields=*,restaurent.name,restaurant.address&expand=restaurant`.



  You may be wondering how things work if you use both the `expand` and `fields` option, and there is overlap. For example, your serialized person model may look like the following by default:

  ```json
  {
    "id": 13322,
    "name": "John Doe",
    "country": {
      "name": "United States"
    }
  }
  ```

  However, you make the following request `HTTP GET /person/13322?include=id,name&expand=country`. You will get the following back:

  ```json
  {
    "id": 13322,
    "name": "John Doe"
  }
  ```

  The `fields` parameter takes precedence over `expand`. That is, if a field is not among the set that is explicitly alllowed, it cannot be expanded. If such a conflict occurs, you will not pay for the extra database queries - the expanded field will be silently abandoned.





  Checks whether a field has been expanded via the request's query parameters.

  **Parameters**

  - **request**: The request object
  - **field**: The name of the field to check



  Checks whether a field has NOT been excluded via either the `omit` parameter or the `fields` parameter.

  **Parameters**

  - **request**: The request object
  - **field**: The name of the field to check



  An experimental filter backend is available to help you automatically reduce the number of SQL queries and their transfer size. _This feature has not been tested thorougly and any help testing and reporting bugs is greatly appreciated._ You can add FlexFieldFilterBackend to `DEFAULT_FILTER_BACKENDS` in the settings:

  ```python


  REST_FRAMEWORK = {
      'DEFAULT_FILTER_BACKENDS': (
          'rest_flex_fields.filter_backends.FlexFieldsFilterBackend',
          
      ),
      
  }
  ```

  It will automatically call `select_related` and `prefetch_related` on the current QuerySet by determining which fields are needed from many-to-many and foreign key-related models. For sparse fields requests (`?omit=fieldX,fieldY` or `?fields=fieldX,fieldY`), the backend will automatically call `only(*field_names)` using only the fields needed for serialization.

  **WARNING:** The optimization currently works only for one nesting level.





  - Adds control over whether recursive expansions are allowed and allows setting the max expansion depth. Thanks @andruten!



  - Various bug fixes. Thanks @michaelschem, @andruten, and @erielias!



  - Improvements to the filter backends for generic foreign key handling and docs generation. Thanks @KrYpTeD974 and @michaelschem!



  - Fixes bug in `FlexFieldsFilterBackend`. Thanks @michaelschem!
  - Adds `FlexFieldsDocsFilterBackend` for schema population. Thanks @Rjevski!



  - Set expandable fields as the default example for expand query parameters in `coreapi.Field`. Thanks @JasperSui!



  - Includes m2m in prefetch_related clause even if they're not expanded. Thanks @pablolmedorado and @ADR-007!



  - Make it possible to use wildcard values with sparse fields requests.



  - Adds OpenAPI support. Thanks @soroush-tabesh!
  - Updates tests for Django 3.2 and fixes deprecation warning. Thanks @giovannicimolin!



  - Fixes bug where custom parameter names were not passed when constructing nested serializers. Thanks @Kandeel4411!



  - Ensures `context` dict is passed down to expanded serializers. Thanks @nikeshyad!



  - No longer auto removes `source` argument if it's equal to the field name.



  - Allows fully qualified import strings for lazy serializer classes.



  - Adds OpenAPI support to experimental filter backend. Thanks @LukasBerka!



  - Django 3.1.1 fix. Thansks @NiyazNz!
  - Docs typo fix. Thanks @zakjholt!



  - Adds `is_included` utility function.



  - Adds options to customize parameter names and wildcard values. Closes #10.



  - Fixes #44, related to the experimental filter backend. Thanks @jsatt!



  - Adds support for `expand`, `omit` and `fields` query parameters for non-GET requests.
    - The common use case is creating/updating a model instance and returning a serialized response with expanded fields
    - Thanks @kotepillar for raising the issue (#25) and @Crocmagnon for the idea of delaying field modification to `to_representation()`.



  - Simplifies declaration of `expandable_fields`
    - If using a tuple, the second element - to define the serializer settings - is now optional.
    - Instead of a tuple, you can now just use the serializer class or a string to lazily reference that class.
    - Updates documentation.



  - Adds support for different ways of passing arrays in query strings. Thanks @sentyaev!
  - Fixes attribute error when map is supplied to split levels utility function. Thanks @hemache!



  - Adds experimental support for automatically SQL query optimization via a `FlexFieldsFilterBackend`. Thanks ADR-007!
  - Adds CircleCI config file. Thanks mikeIFTS!
  - Moves declaration of `expandable_fields` to `Meta` class on serialzer for consistency with DRF (will continue to support declaration as class property)
  - Python 2 is no longer supported. If you need Python 2 support, you can continue to use older versions of this package.



  - Added support for `omit` keyword for field exclusion. Code clean up and improved test coverage.



  - Handle case where `request` is `None` when accessing request object from serializer. Thanks @jsatt!



  - Exposes `FlexFieldsSerializerMixin` in addition to `FlexFieldsModelSerializer`. Thanks @jsatt!



  Tests are found in a simplified DRF project in the `/tests` folder. Install the project requirements and do `./manage.py test` to run them.



  See [License](LICENSE.md).


pkgId: 7e20b038126e77372d037e5415a2c3f739b8b56e706da5f39fcfc8ea8e06b2cb
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-7c1e25b1-7e05-48c4-9f7a-6c81e1f49ee2
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: eef1a4ad6c2ce1e13bf495c5fe3b2fa3180fa98748da68ff3615993fdc834e3f
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-59b06379-df10-43f6-9946-7552acda11e1
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: cebfc19cc34efe5b63fc645e84e321c4ff0e34aecbf392cc3b46f5ba7319f16f
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-03786599-e474-4df1-b0fb-f41570f1586c
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: 899110887071c354cabdb3bc66212a56cb2d76e4ff9ceecfd80122d202d51fc9
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-d9b9f6cf-ee35-4edf-afc6-6158a255ed65
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: f97ee8a418d3f857c3987f9fa24758d971dfcd0b5cef83b0e9d1262da7968d98
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-e8945824-e288-4ae1-b58f-47bd98ac81e7
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: 83cae70fde870b81c54250c798ecb4c6070a1a1d01b667aeeac4169cae378013
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-69f73845-f584-480f-9713-77563b643f0b
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: ee015ef57622b133da9a15c9560f36956fb2e9500de7a9c8a4382418d0a61ceb
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-18cf820e-6a29-4517-bc84-9e9c5c475bb7
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: 2e6c477580f6cd61c86227b14e814527bf79758a98dd1e5c74613c1b31e02ac9
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-8065680b-b90b-48fb-9a40-5bd879f717e4
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: 8eb7f8c1aff1f019fa2f64ddd79ff150d40bdbe764e27980edcb102eabcb01be
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-c8327333-aec6-4a73-9f8d-4a5e1c2d1ce8
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: 08861964ef679fdb86a924c270e7f8a301a93587c97cf58abefda701842b35c7
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-25769f24-1aef-4ce1-840d-ceacd38e95e7
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: c4fefc45d4931156fe06be62f8c41909a83d5642f133a33ae0e09420ec04f789
name: python-dukpy-debuginfo
arch: aarch64
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-25769f24-1aef-4ce1-840d-ceacd38e95e7
rpm_sourcerpm: python-dukpy-0.3.0-1.src.rpm
location_href: 00003549-python-dukpy/python-dukpy-debuginfo-0.3.0-1.aarch64.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: 5e489595fd7fce2f49773bfcbc3f789d4b118ec48dc1291e7d22bbf0ffbc0078
name: python-dukpy-debugsource
arch: aarch64
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-25769f24-1aef-4ce1-840d-ceacd38e95e7
rpm_sourcerpm: python-dukpy-0.3.0-1.src.rpm
location_href: 00003549-python-dukpy/python-dukpy-debugsource-0.3.0-1.aarch64.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: 7595d3508f706ea7265dadd0909c776bbf20915b9493b16bc554567fa4c2a1f5
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-0751cf95-49bc-4675-99cd-9574c8e9ecad
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: d1fc99270584b5279c8adebd9df50f0df0dbb8aca5351f840bac03313de7c1f1
name: python-dulwich-debuginfo
arch: aarch64
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-0751cf95-49bc-4675-99cd-9574c8e9ecad
rpm_sourcerpm: python-dulwich-0.21.3-1.src.rpm
location_href: 00003550-python-dulwich/python-dulwich-debuginfo-0.21.3-1.aarch64.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: 1d2f04567a88e5fa2e6a12dccffbcbe398c0b44657d1a8ba609708e4ebdae8f8
name: python-dulwich-debugsource
arch: aarch64
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-0751cf95-49bc-4675-99cd-9574c8e9ecad
rpm_sourcerpm: python-dulwich-0.21.3-1.src.rpm
location_href: 00003550-python-dulwich/python-dulwich-debugsource-0.21.3-1.aarch64.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: ed8122206201ec4e05e48b25885c0585cc04205af87e6e33a498d79b8d44cb08
name: python-dumbyaml
arch: src
version: 0.9.3
epoch: 0
release: 1
summary: A YAML parser that reads only a restricted version of YAML.
url: https://github.com/crdoconnor/dumbyaml
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4392b816-e047-4405-b2de-d6e0fcac23a8
location_href: 00010925-python-dumbyaml/python-dumbyaml-0.9.3-1.src.rpm
checksum_type: sha256
description:
  DEPRECATED

  Please use StrictYAML instead:

  * https://github.com/crdoconnor/strictyaml
  * http://pypi.python.org/pypi/strictyaml


pkgId: 52542ccea40ab3ced9c0a997aed0f32139a0ad4bf6d076110f0c7f449de4fcd5
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-f05cc9b3-6d7b-4fa0-8500-9a2687303dac
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: a92c05bc9b38cc0bc358fff6458749a18c57fdd1cf7126d4bd59ed65b4c72387
name: python-dwave-qbsolv-debuginfo
arch: aarch64
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-429165c6-723b-4027-8355-d92a8f0d569e
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.aarch64.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: 3a25027c40e2c41680ae4c09e1f52042adceafb2f4cfda465655511b991bed11
name: python-dwave-qbsolv-debugsource
arch: aarch64
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-429165c6-723b-4027-8355-d92a8f0d569e
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.aarch64.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: 3c88d14395e47373ac37c7e031a30d143eef5ba4140fd2ae6416c383d345d91e
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-7c0e111d-8976-44bc-a3a5-25020584c313
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: 59af9cf7f0d82a354da33fbf99674b4494aa3dfb7e971bfe20d17806a19064be
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-7fcaf6aa-bd30-4c26-aeb6-26fd75b97871
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: ad8818889b6e70034dd26dc0a27aae6e190c61fe9a90728780fe870d531028a1
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-9adf5df6-f34a-48b6-a32c-3c68ec3251bd
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: d203422f296c698317a3b495abff87c9c278bacf70d4bb28f5d5a2056e447615
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-e5c5cd49-f2ac-4d2f-85d2-bff5b3e62af1
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: a97056b73f0ca4db71db761d00ba69e143c4fe223c86a3ec2d1536f2fae67efa
name: python-ebaysdk
arch: src
version: 2.2.0
epoch: 0
release: 1
summary: eBay SDK for Python
url: https://github.com/timotheus/ebaysdk-python
rpm_license: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-4e8455ae-bb3e-46e7-a436-751a60d31fce
location_href: 00012073-python-ebaysdk/python-ebaysdk-2.2.0-1.src.rpm
checksum_type: sha256
description:
  This SDK is a programatic inteface into the eBay
  APIs. It simplifies development and cuts development time by standerizing
  calls, response processing, error handling, debugging across the Finding,
  Shopping, Merchandising, & Trading APIs.


pkgId: b2e52bbed2dff6d30cf3f7d5d4766dd092de7bbaa8606808db99a2d86ab30eab
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-665b69b2-c2d1-4cb9-8139-64baf03eed21
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: d96fe3978787d4b89ed5821c4dd47de1f5bc378be561219cc2084817f114163b
name: python-ecl-data-io
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: A (lazy) parser and writer for the ecl output format.
url: https://github.com/equinor/ecl-data-io
rpm_license: LGPL-3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-f60d9ac0-79ee-4cdc-b066-f8b8b499ef51
location_href: 00014030-python-ecl-data-io/python-ecl-data-io-2.1.0-1.src.rpm
checksum_type: sha256
description:
  Parser for the ecl output format, such as found in files with
  extensions .UNRST, .EGRID, .INIT, etc. and also the corresponding
  ascii files with extension .FUNRST, .FEGRID, .FINIT, etc.


pkgId: 5f12ee7dae2c857b2ce6f4b9684e0ebe3803adc5eab010b9af217478f37c1296
name: python-editables
arch: src
version: 0.3
epoch: 0
release: 1
summary: Editable installations
url: https://github.com/pfmoore/editables
rpm_license: MIT
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-3d4375aa-a93c-4bd7-a873-750d55b08210
location_href: 00013189-python-editables/python-editables-0.3-1.src.rpm
checksum_type: sha256
description:
  This library supports the building of wheels which, when installed, will
  expose packages in a local directory on `sys.path` in "editable mode". In
  other words, changes to the package source will be  reflected in the package
  visible to Python, without needing a reinstall.



  Suppose you want to build a wheel for your project `foo`. Your project is
  located in the directory `/path/to/foo`. Under that directory, you have a
  `src` directory containing your project, which is a package called `foo`
  and a Python module called `bar.py`. So your directory structure looks like
  this:

  ```
  /path/to/foo
  |
  +-- src
  |   +-- foo
  |   |   +-- __init__.py
  |   +-- bar.py
  |
  +-- setup.py
  +-- other files
  ```

  Build your wheel as follows:

  ```python
  from editables import EditableProject

  my_project = EditableProject("foo", "/path/to/foo")
  my_project.add_to_path("src")


  wheel = BuildAWheel()


  for name, content in my_project.files():
      wheel.add_file(name, content)


  for dep in my_project.dependencies():
      wheel.metadata.dependencies.add(dep)
  ```

  The resulting wheel will, when installed, put the project `src` directory on
  `sys.path` so that editing the original source will take effect without needing
  a reinstall (i.e., as "editable" packages). The project is exposed on `sys.path`
  by adding a single `.pth` file, named after the project, into the wheel.

  For more details, including how to control what gets exposed more precisely, see
  [the documentation](https://editables.readthedocs.io/en/latest/).

  Note that this project doesn't build wheels directly. That's the responsibility
  of the calling code.



  This project supports the same versions of Python as pip does. Currently
  that is Python 3.7 and later, and PyPy3 (although we don't test against
  PyPy).


pkgId: f5725e587d8dbb4e136cbda52cb758623c08fa11054a705d8c4bdf9d4f04a7a3
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-5a992bf8-fea3-46dd-bc8c-cd6b44e6bcfd
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: 49a34edc79c3c290293008739d41a2aa6749dba1fcde4208f4d56db28dc98e2d
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-ae979c1d-d1d2-4e6b-a4cb-726c00db712a
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: 1e103dd92593ab7a47e7b7bf28c4bf7b44dec2dbf419e86b060b73e77da4aac2
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-349ad6a5-05e7-4ed3-a45b-2d27c7e3333d
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: 75253c6e5dc295a8a237cab8677445fe88405e76da92b77cef7d2a5a6377d7e7
name: python-edx-auth-backends
arch: src
version: 4.1.0
epoch: 0
release: 1
summary: Custom edX authentication backends and pipeline steps
url: https://github.com/edx/auth-backends
rpm_license: AGPL
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-46d0c7e7-fa09-4bae-a7a9-3a4942c0d2bf
location_href: 00013812-python-edx-auth-backends/python-edx-auth-backends-4.1.0-1.src.rpm
checksum_type: sha256
description:
  This package contains custom authentication backends, views, and pipeline steps used by edX services for single sign-on.
  This package is compatible with Python 3.8, Django 2.2 and Django 3.0
  We currently support OAuth 2.0 authentication. Support for OpenID Connect (OIDC) was removed as of version 3.0. Use version 2.x if you require OIDC and are not able to migrate to OAuth2.


pkgId: 9caa002f681442112a350442d5043e3ecc536b0baee2fe3a82a728b4cb6f5ec5
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-9c173e05-d80c-4e79-9ac2-7452c8ba418d
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: d515e709a24958c5cb4d71965fbe7f3b958a0bc36a0213b7565c9b742404f0db
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-82afa078-dcc2-4fc9-bd51-545314e4124c
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: 69181f93802d38943daebd9b006d5841a33a65ea4565e9ee0d3c625d07e52372
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-82afa078-dcc2-4fc9-bd51-545314e4124c
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: c36a73391a21ef51c2ba35dee0d746f1604ca2f4942f0f69a88a0ca2946bc08f
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-c9079ef2-634a-4b0a-acaf-9cc4d7e4e279
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: 3606e49559dcb208b4c1c4b411d590e59a866e4c3967304977983496d4690f39
name: python-edx-rest-api-client
arch: src
version: 5.5.0
epoch: 0
release: 1
summary: Slumber client used to access various edX Platform REST APIs.
url: https://github.com/edx/edx-rest-api-client
rpm_license: Apache
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-6914e9c2-9463-47a0-82ae-8f0ec31daece
location_href: 00013167-python-edx-rest-api-client/python-edx-rest-api-client-5.5.0-1.src.rpm
checksum_type: sha256
description:
  The edX REST API Client (henceforth, client) allows users to communicate with various edX REST APIs, including the `E-Commerce Service`_ and the `Programs Service`_.


pkgId: dd7731721d80a715a30a557c25fcbc7e7b01d4fce822dad9445d1dd0c455fea0
name: python-edx-toggles
arch: src
version: 5.0.0
epoch: 0
release: 1
summary: Library and utilities for feature toggles
url: https://github.com/edx/edx-toggles
rpm_license: AGPL 3.0
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-7e171173-b9b9-4db8-bf01-6ccd905a38f5
location_href: 00013776-python-edx-toggles/python-edx-toggles-5.0.0-1.src.rpm
checksum_type: sha256
description:
  |pypi-badge| |ci-badge| |codecov-badge| |doc-badge| |pyversions-badge|
  |license-badge|
  Library and utilities for implementing and reporting on feature toggles.
  Documentation is on `Read the Docs`_.  Code repository is on `GitHub`_.
  See the `scripts README`_ for more information on the scripts for reporting on the status of
  feature toggles.


pkgId: 8520c3e5f081e33bb8bf90dd76c5eb14f2da12f85afc08a21e212d6edf0ee352
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-eec8e559-5365-41f7-8d9e-e2f057e17582
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: d821468c77521f0254c4f1b5e24f7d900e900ab1cea6360631ce18c013f0a2f9
name: python-efel-debuginfo
arch: aarch64
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-eec8e559-5365-41f7-8d9e-e2f057e17582
rpm_sourcerpm: python-efel-4.1.63-1.src.rpm
location_href: 00003561-python-efel/python-efel-debuginfo-4.1.63-1.aarch64.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: 39a72a5ba0f03f168c6f69d7562abdccb8f7c17ad47f76409f772b52ae67ccf3
name: python-efel-debugsource
arch: aarch64
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-eec8e559-5365-41f7-8d9e-e2f057e17582
rpm_sourcerpm: python-efel-4.1.63-1.src.rpm
location_href: 00003561-python-efel/python-efel-debugsource-4.1.63-1.aarch64.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: 00cd9c6838ff8b683c369781fac9cdd0eb83295dce5ff2d426d41418ef470d47
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-1828e35b-1514-4d9a-aeea-684975829f32
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: e33b09e6c904bfdce5ec1ff541ef92aed72e1566aafd6891f7ed1169c5f6c3fa
name: python-eight
arch: src
version: 1.0.1
epoch: 0
release: 1
summary: Python 2 to the power of 3. A lightweight porting helper library.
url: https://github.com/kislyuk/eight
rpm_license: Apache Software License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-5c994972-83a6-4439-a426-cb9531fb8ea9
location_href: 00012747-python-eight/python-eight-1.0.1-1.src.rpm
checksum_type: sha256
description:
  Eight is a Python module that provides a minimalist compatibility layer between Python 3 and 2. Eight lets you write
  code for Python 3.3+ while providing limited compatibility with Python 2.7 with no code changes.  Eight is inspired by
  `six <https://pythonhosted.org/six/>`_, `nine <https://github.com/nandoflorestan/nine>`_, and `python-future
  <https://github.com/PythonCharmers/python-future>`_, but provides better internationalization (i18n) support, is more
  lightweight, easier to use, and unambiguously biased toward Python 3 code: if you remove eight from your code, it will
  continue to function exactly as it did with eight on Python 3.
  To write code for Python 3 that is portable to Python 2, you may also want to read Armin Ronacher's excellent `Python 3
  porting guide <http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/>`_, as well as the official
  `porting guide <http://docs.python.org/3/howto/pyporting.html>`_.
  Writing ``from eight import *`` in your code is a no-op in Python 3. In Python 2, it binds a bunch of Python 3 names to
  their Python 2 equivalents. Also, if you need to import a module or module member that was renamed in Python 3, writing
  ``from eight import <module>`` will do the right thing (equivalent to ``import <module>`` on Python 3 and ``import
  <old_name> as <module>`` on Python 2). Finally, eight can optionally wrap your standard streams and environment variable
  I/O to use text, not bytes (see below).


pkgId: e18b1f57b18ff07022c8cc198eb27ea24b3b5f06b7f83f7f9077a362f91ab23e
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-14231d6c-838b-41c8-9189-edc0e1ce524e
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: dd326ba3fd18f823727787a1a64b17b3650832f5ba5b0bbc2188ebf0ff7fd42d
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-d2609d6d-2406-4305-87f7-566673a1e627
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: 411d1faed4e4a2df1629cccc73ab46185ea90a1b4139af057e723699b86218df
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-20327f7d-6caf-4118-a5ec-749f55b9c69f
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: 948624d6739df3d09a99450a4935d4c9b01300a60036d9711d80bb290a4a4810
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-13473c68-e062-423a-a820-3692c92bdd33
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: b8edf4bd1d4fdc1421265a8abcd708164a89fd52e30e14e151e21e8ad7b8e2e9
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-5a6ae1bd-7931-46dd-85d4-5d1d993b80a9
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: fcfb7851a6cede13c172f2e9888c180da551de1f39e8bfabffe573f9c0df6036
name: python-elephant-debuginfo
arch: aarch64
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-5a6ae1bd-7931-46dd-85d4-5d1d993b80a9
rpm_sourcerpm: python-elephant-0.12.0-1.src.rpm
location_href: 00003562-python-elephant/python-elephant-debuginfo-0.12.0-1.aarch64.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: 224ee7abee7753136f620188f7e1303567f0e91ad4b03668189067a8bce72fec
name: python-elephant-debugsource
arch: aarch64
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-5a6ae1bd-7931-46dd-85d4-5d1d993b80a9
rpm_sourcerpm: python-elephant-0.12.0-1.src.rpm
location_href: 00003562-python-elephant/python-elephant-debugsource-0.12.0-1.aarch64.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: 2896521635e559a5b2c70a69ee28f644001a495af012c2529294930736c28e90
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-04032c50-d6d2-4948-a444-28a6dda468ab
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: 98fe6035b29d8795fe52464a523be34c8264f640ee1beb027738579222feccf3
name: python-emails
arch: src
version: 0.6
epoch: 0
release: 1
summary: Modern python library for emails.
url: https://github.com/lavr/python-emails
rpm_license: BSD License
rpm_vendor: openEuler Copr - user mywaaagh_admin
rpm_group: Unspecified
rpm_buildhost: resalloc-598c4f2f-6028-4b2b-89ed-ee79557332d3
location_href: 00011135-python-emails/python-emails-0.6-1.src.rpm
checksum_type: sha256
description:
  python-emails
  ~~~~~~~~~~~~~

  Modern python library for email.

  Build message:

     >>> import emails
     >>> message = emails.html(html="<p>Hi!<br>Here is your receipt...",
                            subject="Your receipt No. 567098123",
                            mail_from=('Some Store', 'store@somestore.com'))
     >>> message.attach(data=open('bill.pdf'), filename='bill.pdf')

  send message and get response from smtp server:

     >>> r = message.send(to='s@lavr.me', smtp={'host': 'aspmx.l.google.com', 'timeout': 5})
     >>> assert r.status_code == 250

  and more:

   * DKIM signature
   * Render body from template
   * Flask extension and Django integration
   * Message body transformation methods
   * Load message from url or from file


  Links
  `````

  * `documentation <http://python-emails.readthedocs.org/>`_
  * `source code <http://github.com/lavr/python-emails>`_


