django-api-versioning 0.1.0__tar.gz → 0.1.2__tar.gz

{django-api-versioning-0.1.0/django_api_versioning.egg-info → django-api-versioning-0.1.2}/PKG-INFO

@@ -1,7 +1,7 @@
 Metadata-Version: 2.1
 Name: django-api-versioning
-Version: 0.1.0
-Summary: A powerful and flexible library for managing API versioning in Django projects.
+Version: 0.1.2
+Summary: Django API versioning decorator provides a solution for managing multiple API versions within the Django framework, enabling versioning through URLs with backward compatibility and automatically registering routes.
 Home-page: https://github.com/mojtaba-arvin/django-api-versioning
 Author: Mojtaba Arvin
 Author-email: ArvinDevDay@gmail.com
@@ -15,12 +15,11 @@ Classifier: Development Status :: 3 - Alpha
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: MIT License
 Classifier: Operating System :: OS Independent
-Requires-Python: >=3.9
+Requires-Python: >=3.6
 Description-Content-Type: text/markdown
 Provides-Extra: dev
 License-File: LICENSE
 
-
 # Django API Versioning
 
 [![PyPI version](https://badge.fury.io/py/django-api-versioning.svg)](https://badge.fury.io/py/django-api-versioning)
@@ -28,7 +27,7 @@ License-File: LICENSE
 [![codecov](https://codecov.io/gh/mojtaba-arvin/django-api-versioning/branch/main/graph/badge.svg)](https://codecov.io/gh/mojtaba-arvin/django-api-versioning)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-**Django API Versioning** is a powerful and flexible library for managing API versioning in Django projects. It allows you to easily define and manage different versions of your API endpoints using decorators, ensuring backward compatibility and clean code organization.
+**Django API Versioning** is a powerful and flexible library for managing [API versioning in Django](https://github.com/mojtaba-arvin/django-api-versioning) projects. It allows you to easily define and manage different versions of your API endpoints using decorators, ensuring backward compatibility and clean code organization.
 
 ## Features
 
@@ -41,7 +40,7 @@ License-File: LICENSE
 
 ## Installation
 
-You can install Django API Versioning via pip:
+You can [install Django API Versioning](https://pypi.org/project/django-api-versioning/) via pip:
 
 ```bash
 pip install django-api-versioning
@@ -95,7 +94,6 @@ or you have already have a `ROOT_URLCONF` in settings, you only need to import t
 
 The `endpoint` decorator can be used in both function-based views (FBVs) and class-based views (CBVs). It's also fully compatible with `Django Rest Framework (DRF)`. The decorator allows you to define versioning for your API views and supports backward compatibility by default and you don't need to pass `backward=True` flag to the `endpoint` decorator.
 
-
 #### Example for Function-Based Views (FBVs):
 
 ```python
@@ -110,6 +108,7 @@ def users_view(request):
 In this example, the `users_view` function is decorated with the endpoint decorator. This specifies that the view is accessible under version `2` of the API and **supports backward compatibility**. The `backward=True` flag as default ensures that users can also access the previous version (version `1`) at `/api/v1/account_app/users`.
 
 #### Example for Class-Based Views (CBVs):
+
 For class-based views, you can apply the decorator to methods such as `get`, `post`, or any other HTTP method you need to handle. Here’s an example:
 
 ```python
@@ -130,7 +129,6 @@ class UsersView(View):
 
 If you have already installed [Django Rest Framework](https://www.django-rest-framework.org/#installation), the `endpoint` decorator can be easily applied to APIView or viewsets. Here’s an example with a DRF APIView:
 
-
 ```python
 from rest_framework.views import APIView
 from rest_framework.response import Response
@@ -144,25 +142,26 @@ class UsersAPIView(APIView):
 ```
 
 #### URL Generation Based on Versioning:
+
 Once the decorator is applied, the URLs for your API will be generated based on the version specified in the decorator. For example, if the `API_MIN_VERSION` in your settings.py is set to `1` and the version in the decorator is set to `2`, the following URLs will be available:
 
-* `/api/v1/account_app/users`
-* `/api/v2/account_app/users`
+- `/api/v1/account_app/users`
+- `/api/v2/account_app/users`
 
 The `API_MIN_VERSION` setting ensures that users can access the API using different versions, providing backward compatibility. You can adjust which versions are considered valid by modifying the `API_MIN_VERSION` and `version` numbers in the decorators.
 
 #### Additional Configuration Options:
 
 **Without `app_name`:** If you don't pass `app_name` in the decorator, like this:
+
 ```python
 @endpoint("users", version=2, view_name="users_list_api")
 ```
 
 The generated URLs will be:
 
-* `/api/v1/users`
-* `/api/v2/users`
-
+- `/api/v1/users`
+- `/api/v2/users`
 
 **Without `version`:** If you don't pass `version` in the decorator, like this:
 
@@ -172,7 +171,7 @@ The generated URLs will be:
 
 API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for that view. The only URL generated will be:
 
-* `/users`
+- `/users`
 
 **Setting `backward=False`:** By default, the `backward` parameter is set to `True`, which ensures backward compatibility. If you explicitly set `backward=False`, like this:
 
@@ -182,7 +181,7 @@ API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for
 
 The generated URL will be only version 2:
 
-* `api/v2/users`
+- `api/v2/users`
 
 4. Run the Server:
 
@@ -191,16 +190,21 @@ python manage.py runserver
 ```
 
 ## Notes
+
 ### 1. `API_BASE_PATH` in settings Must Include ‍‍`{version}`:
+
 The `API_BASE_PATH` should always include `{version}` to ensure proper API versioning. This is important for correctly mapping API routes to different versions.
 
 ### 2. Using `app_name` in the `endpoint` decorator:
+
 It's recommended to fill in the `app_name` in the `endpoint` decorator to make the API URLs **more unique and organized**. This ensures that the routes are scoped under the correct app, avoiding potential conflicts and making them easier to manage.
 
 ### 3. Views with Version Less Than `API_MIN_VERSION` Are Automatically Ignored:
+
 Any view whose `version` is less than the `API_MIN_VERSION` will be automatically ignored. This means clients will no longer have access to these older versions, **without the need to manually edit or remove code**. This is handled automatically by the package.
 
 ### 4. URLs for Versions Between `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION`:
+
 Endpoints that have versions within the range defined by `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION` will always have a corresponding URL generated. This ensures that only valid versions will be accessible, providing flexibility in version management.
 
 ### `endpoint` Decorator Function Definition
@@ -221,7 +225,7 @@ def endpoint(
     - Uses `API_MIN_VERSION` and `API_MAX_VERSION` from Django settings.
     - Supports backward compatibility by registering multiple versions if needed.
     - Ensures that no version lower than `API_MIN_VERSION` is registered.
-    
+
     Args:
         postfix (str): The endpoint suffix (e.g., "users" → "api/v1/users").
         version (Optional[int]): The version of the API. Defaults to None (unversioned).
@@ -238,7 +242,6 @@ def endpoint(
     """
 ```
 
-
 ## Contributing
 
 Feel free to open an issue or submit a pull request with any improvements or bug fixes. We appreciate contributions to enhance this package!

{django-api-versioning-0.1.0 → django-api-versioning-0.1.2}/README.md

@@ -1,4 +1,3 @@
-
 # Django API Versioning
 
 [![PyPI version](https://badge.fury.io/py/django-api-versioning.svg)](https://badge.fury.io/py/django-api-versioning)
@@ -6,7 +5,7 @@
 [![codecov](https://codecov.io/gh/mojtaba-arvin/django-api-versioning/branch/main/graph/badge.svg)](https://codecov.io/gh/mojtaba-arvin/django-api-versioning)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-**Django API Versioning** is a powerful and flexible library for managing API versioning in Django projects. It allows you to easily define and manage different versions of your API endpoints using decorators, ensuring backward compatibility and clean code organization.
+**Django API Versioning** is a powerful and flexible library for managing [API versioning in Django](https://github.com/mojtaba-arvin/django-api-versioning) projects. It allows you to easily define and manage different versions of your API endpoints using decorators, ensuring backward compatibility and clean code organization.
 
 ## Features
 
@@ -19,7 +18,7 @@
 
 ## Installation
 
-You can install Django API Versioning via pip:
+You can [install Django API Versioning](https://pypi.org/project/django-api-versioning/) via pip:
 
 ```bash
 pip install django-api-versioning
@@ -73,7 +72,6 @@ or you have already have a `ROOT_URLCONF` in settings, you only need to import t
 
 The `endpoint` decorator can be used in both function-based views (FBVs) and class-based views (CBVs). It's also fully compatible with `Django Rest Framework (DRF)`. The decorator allows you to define versioning for your API views and supports backward compatibility by default and you don't need to pass `backward=True` flag to the `endpoint` decorator.
 
-
 #### Example for Function-Based Views (FBVs):
 
 ```python
@@ -88,6 +86,7 @@ def users_view(request):
 In this example, the `users_view` function is decorated with the endpoint decorator. This specifies that the view is accessible under version `2` of the API and **supports backward compatibility**. The `backward=True` flag as default ensures that users can also access the previous version (version `1`) at `/api/v1/account_app/users`.
 
 #### Example for Class-Based Views (CBVs):
+
 For class-based views, you can apply the decorator to methods such as `get`, `post`, or any other HTTP method you need to handle. Here’s an example:
 
 ```python
@@ -108,7 +107,6 @@ class UsersView(View):
 
 If you have already installed [Django Rest Framework](https://www.django-rest-framework.org/#installation), the `endpoint` decorator can be easily applied to APIView or viewsets. Here’s an example with a DRF APIView:
 
-
 ```python
 from rest_framework.views import APIView
 from rest_framework.response import Response
@@ -122,25 +120,26 @@ class UsersAPIView(APIView):
 ```
 
 #### URL Generation Based on Versioning:
+
 Once the decorator is applied, the URLs for your API will be generated based on the version specified in the decorator. For example, if the `API_MIN_VERSION` in your settings.py is set to `1` and the version in the decorator is set to `2`, the following URLs will be available:
 
-* `/api/v1/account_app/users`
-* `/api/v2/account_app/users`
+- `/api/v1/account_app/users`
+- `/api/v2/account_app/users`
 
 The `API_MIN_VERSION` setting ensures that users can access the API using different versions, providing backward compatibility. You can adjust which versions are considered valid by modifying the `API_MIN_VERSION` and `version` numbers in the decorators.
 
 #### Additional Configuration Options:
 
 **Without `app_name`:** If you don't pass `app_name` in the decorator, like this:
+
 ```python
 @endpoint("users", version=2, view_name="users_list_api")
 ```
 
 The generated URLs will be:
 
-* `/api/v1/users`
-* `/api/v2/users`
-
+- `/api/v1/users`
+- `/api/v2/users`
 
 **Without `version`:** If you don't pass `version` in the decorator, like this:
 
@@ -150,7 +149,7 @@ The generated URLs will be:
 
 API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for that view. The only URL generated will be:
 
-* `/users`
+- `/users`
 
 **Setting `backward=False`:** By default, the `backward` parameter is set to `True`, which ensures backward compatibility. If you explicitly set `backward=False`, like this:
 
@@ -160,7 +159,7 @@ API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for
 
 The generated URL will be only version 2:
 
-* `api/v2/users`
+- `api/v2/users`
 
 4. Run the Server:
 
@@ -169,16 +168,21 @@ python manage.py runserver
 ```
 
 ## Notes
+
 ### 1. `API_BASE_PATH` in settings Must Include ‍‍`{version}`:
+
 The `API_BASE_PATH` should always include `{version}` to ensure proper API versioning. This is important for correctly mapping API routes to different versions.
 
 ### 2. Using `app_name` in the `endpoint` decorator:
+
 It's recommended to fill in the `app_name` in the `endpoint` decorator to make the API URLs **more unique and organized**. This ensures that the routes are scoped under the correct app, avoiding potential conflicts and making them easier to manage.
 
 ### 3. Views with Version Less Than `API_MIN_VERSION` Are Automatically Ignored:
+
 Any view whose `version` is less than the `API_MIN_VERSION` will be automatically ignored. This means clients will no longer have access to these older versions, **without the need to manually edit or remove code**. This is handled automatically by the package.
 
 ### 4. URLs for Versions Between `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION`:
+
 Endpoints that have versions within the range defined by `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION` will always have a corresponding URL generated. This ensures that only valid versions will be accessible, providing flexibility in version management.
 
 ### `endpoint` Decorator Function Definition
@@ -199,7 +203,7 @@ def endpoint(
     - Uses `API_MIN_VERSION` and `API_MAX_VERSION` from Django settings.
     - Supports backward compatibility by registering multiple versions if needed.
     - Ensures that no version lower than `API_MIN_VERSION` is registered.
-    
+
     Args:
         postfix (str): The endpoint suffix (e.g., "users" → "api/v1/users").
         version (Optional[int]): The version of the API. Defaults to None (unversioned).
@@ -216,7 +220,6 @@ def endpoint(
     """
 ```
 
-
 ## Contributing
 
 Feel free to open an issue or submit a pull request with any improvements or bug fixes. We appreciate contributions to enhance this package!

{django-api-versioning-0.1.0 → django-api-versioning-0.1.2}/django_api_versioning/decorators.py

@@ -20,10 +20,16 @@ def endpoint(
     - Ensures that no version lower than `API_MIN_VERSION` is registered.
     
     Args:
-        postfix (str): The endpoint suffix (e.g., "users" → "api/v1/users").
-        version (Optional[int]): The version of the API. Defaults to None (unversioned).
-        backward (bool): If True, registers routes for all versions from `API_MIN_VERSION` up to the current version, which is less than or equal to `API_MAX_VERSION`. Defaults to True.
-        app_name (Optional[str]): The app name to be prefixed to the route.
+        postfix (str): The endpoint suffix (e.g., "users" →
+                    "api/v1/users").
+        version (Optional[int]): The version of the API. Defaults
+                                to None (unversioned).
+        backward (bool): If True, registers routes for all versions
+                        from `API_MIN_VERSION` up to the current
+                        version, which is less than or equal to
+                        `API_MAX_VERSION`. Defaults to True.
+        app_name (Optional[str]): The app name to be prefixed to
+                                the route.
         view_name (Optional[str]): The custom view name for Django.
 
     Returns:

{django-api-versioning-0.1.0 → django-api-versioning-0.1.2}/django_api_versioning/settings.py

@@ -2,7 +2,7 @@ import logging
 from django.conf import settings
 from django.core.exceptions import ImproperlyConfigured
 from dataclasses import dataclass
-from typing import Optional
+from typing import Optional, Any
 from .exceptions import VersionTypeError, VersionRangeError, VersioningError
 
 # Initialize logger
@@ -10,14 +10,14 @@ logger = logging.getLogger(__name__)
 
 @dataclass
 class APISettings:
-
+    
     API_BASE_PATH: str = "api/v{version}/"
     API_MAX_VERSION: int = 1
     API_MIN_VERSION: int = 1
     ROOT_URLCONF: str = 'django_api_versioning.urls'
 
     @staticmethod
-    def get_setting(name: str, default: Optional[any] = None) -> Optional[any]:
+    def get_setting(name: str, default: Optional[Any] = None) -> Any:
         """
         Reads the setting from Django settings and provides a default if not found.
         """
@@ -30,9 +30,7 @@ class APISettings:
         
         # Ensure that API_BASE_PATH ends with a "/"
         if not self.API_BASE_PATH.endswith("/"):
-            logger.warning(
-                "API_BASE_PATH should end with a '/'. Adding '/' automatically."
-            )
+            logger.warning("API_BASE_PATH should end with a '/'. Adding '/' automatically.")
             self.API_BASE_PATH += "/"
 
         # Validate version settings

{django-api-versioning-0.1.0 → django-api-versioning-0.1.2/django_api_versioning.egg-info}/PKG-INFO

@@ -1,7 +1,7 @@
 Metadata-Version: 2.1
 Name: django-api-versioning
-Version: 0.1.0
-Summary: A powerful and flexible library for managing API versioning in Django projects.
+Version: 0.1.2
+Summary: Django API versioning decorator provides a solution for managing multiple API versions within the Django framework, enabling versioning through URLs with backward compatibility and automatically registering routes.
 Home-page: https://github.com/mojtaba-arvin/django-api-versioning
 Author: Mojtaba Arvin
 Author-email: ArvinDevDay@gmail.com
@@ -15,12 +15,11 @@ Classifier: Development Status :: 3 - Alpha
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: MIT License
 Classifier: Operating System :: OS Independent
-Requires-Python: >=3.9
+Requires-Python: >=3.6
 Description-Content-Type: text/markdown
 Provides-Extra: dev
 License-File: LICENSE
 
-
 # Django API Versioning
 
 [![PyPI version](https://badge.fury.io/py/django-api-versioning.svg)](https://badge.fury.io/py/django-api-versioning)
@@ -28,7 +27,7 @@ License-File: LICENSE
 [![codecov](https://codecov.io/gh/mojtaba-arvin/django-api-versioning/branch/main/graph/badge.svg)](https://codecov.io/gh/mojtaba-arvin/django-api-versioning)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-**Django API Versioning** is a powerful and flexible library for managing API versioning in Django projects. It allows you to easily define and manage different versions of your API endpoints using decorators, ensuring backward compatibility and clean code organization.
+**Django API Versioning** is a powerful and flexible library for managing [API versioning in Django](https://github.com/mojtaba-arvin/django-api-versioning) projects. It allows you to easily define and manage different versions of your API endpoints using decorators, ensuring backward compatibility and clean code organization.
 
 ## Features
 
@@ -41,7 +40,7 @@ License-File: LICENSE
 
 ## Installation
 
-You can install Django API Versioning via pip:
+You can [install Django API Versioning](https://pypi.org/project/django-api-versioning/) via pip:
 
 ```bash
 pip install django-api-versioning
@@ -95,7 +94,6 @@ or you have already have a `ROOT_URLCONF` in settings, you only need to import t
 
 The `endpoint` decorator can be used in both function-based views (FBVs) and class-based views (CBVs). It's also fully compatible with `Django Rest Framework (DRF)`. The decorator allows you to define versioning for your API views and supports backward compatibility by default and you don't need to pass `backward=True` flag to the `endpoint` decorator.
 
-
 #### Example for Function-Based Views (FBVs):
 
 ```python
@@ -110,6 +108,7 @@ def users_view(request):
 In this example, the `users_view` function is decorated with the endpoint decorator. This specifies that the view is accessible under version `2` of the API and **supports backward compatibility**. The `backward=True` flag as default ensures that users can also access the previous version (version `1`) at `/api/v1/account_app/users`.
 
 #### Example for Class-Based Views (CBVs):
+
 For class-based views, you can apply the decorator to methods such as `get`, `post`, or any other HTTP method you need to handle. Here’s an example:
 
 ```python
@@ -130,7 +129,6 @@ class UsersView(View):
 
 If you have already installed [Django Rest Framework](https://www.django-rest-framework.org/#installation), the `endpoint` decorator can be easily applied to APIView or viewsets. Here’s an example with a DRF APIView:
 
-
 ```python
 from rest_framework.views import APIView
 from rest_framework.response import Response
@@ -144,25 +142,26 @@ class UsersAPIView(APIView):
 ```
 
 #### URL Generation Based on Versioning:
+
 Once the decorator is applied, the URLs for your API will be generated based on the version specified in the decorator. For example, if the `API_MIN_VERSION` in your settings.py is set to `1` and the version in the decorator is set to `2`, the following URLs will be available:
 
-* `/api/v1/account_app/users`
-* `/api/v2/account_app/users`
+- `/api/v1/account_app/users`
+- `/api/v2/account_app/users`
 
 The `API_MIN_VERSION` setting ensures that users can access the API using different versions, providing backward compatibility. You can adjust which versions are considered valid by modifying the `API_MIN_VERSION` and `version` numbers in the decorators.
 
 #### Additional Configuration Options:
 
 **Without `app_name`:** If you don't pass `app_name` in the decorator, like this:
+
 ```python
 @endpoint("users", version=2, view_name="users_list_api")
 ```
 
 The generated URLs will be:
 
-* `/api/v1/users`
-* `/api/v2/users`
-
+- `/api/v1/users`
+- `/api/v2/users`
 
 **Without `version`:** If you don't pass `version` in the decorator, like this:
 
@@ -172,7 +171,7 @@ The generated URLs will be:
 
 API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for that view. The only URL generated will be:
 
-* `/users`
+- `/users`
 
 **Setting `backward=False`:** By default, the `backward` parameter is set to `True`, which ensures backward compatibility. If you explicitly set `backward=False`, like this:
 
@@ -182,7 +181,7 @@ API versioning will be disabled (`API_BASE_PATH` as prefix will be removed) for
 
 The generated URL will be only version 2:
 
-* `api/v2/users`
+- `api/v2/users`
 
 4. Run the Server:
 
@@ -191,16 +190,21 @@ python manage.py runserver
 ```
 
 ## Notes
+
 ### 1. `API_BASE_PATH` in settings Must Include ‍‍`{version}`:
+
 The `API_BASE_PATH` should always include `{version}` to ensure proper API versioning. This is important for correctly mapping API routes to different versions.
 
 ### 2. Using `app_name` in the `endpoint` decorator:
+
 It's recommended to fill in the `app_name` in the `endpoint` decorator to make the API URLs **more unique and organized**. This ensures that the routes are scoped under the correct app, avoiding potential conflicts and making them easier to manage.
 
 ### 3. Views with Version Less Than `API_MIN_VERSION` Are Automatically Ignored:
+
 Any view whose `version` is less than the `API_MIN_VERSION` will be automatically ignored. This means clients will no longer have access to these older versions, **without the need to manually edit or remove code**. This is handled automatically by the package.
 
 ### 4. URLs for Versions Between `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION`:
+
 Endpoints that have versions within the range defined by `API_MIN_VERSION` <= `version` <= `API_MAX_VERSION` will always have a corresponding URL generated. This ensures that only valid versions will be accessible, providing flexibility in version management.
 
 ### `endpoint` Decorator Function Definition
@@ -221,7 +225,7 @@ def endpoint(
     - Uses `API_MIN_VERSION` and `API_MAX_VERSION` from Django settings.
     - Supports backward compatibility by registering multiple versions if needed.
     - Ensures that no version lower than `API_MIN_VERSION` is registered.
-    
+
     Args:
         postfix (str): The endpoint suffix (e.g., "users" → "api/v1/users").
         version (Optional[int]): The version of the API. Defaults to None (unversioned).
@@ -238,7 +242,6 @@ def endpoint(
     """
 ```
 
-
 ## Contributing
 
 Feel free to open an issue or submit a pull request with any improvements or bug fixes. We appreciate contributions to enhance this package!

{django-api-versioning-0.1.0 → django-api-versioning-0.1.2}/setup.py

@@ -5,10 +5,16 @@ with open("README.md", "r", encoding="utf-8") as fh:
 
 setup(
     name="django-api-versioning",
-    version="0.1.0",
+    version="0.1.2",
     author="Mojtaba Arvin",
     author_email="ArvinDevDay@gmail.com",
-    description="A powerful and flexible library for managing API versioning in Django projects.",
+    description= (
+    "Django API versioning decorator provides a solution "
+    "for managing multiple API versions within "
+    "the Django framework, enabling versioning "
+    "through URLs with backward compatibility "
+    "and automatically registering routes."
+    ),
     long_description=long_description,
     long_description_content_type="text/markdown",
     url="https://github.com/mojtaba-arvin/django-api-versioning",
@@ -23,7 +29,7 @@ setup(
         "License :: OSI Approved :: MIT License",
         "Operating System :: OS Independent",
     ],
-    python_requires=">=3.9",
+    python_requires=">=3.6",
     install_requires=[
         "Django>=3.2",
     ],