crudclient 0.1.3

No project description provided

Create base client model for restful libraries

Badges and quicklinks

Project Overview

Project Overview

This project is a foundational framework designed to streamline the creation of API clients and CRUD (Create, Read, Update, Delete) classes. It is intended to be a reusable package that can be implemented in various projects, providing a consistent and DRY (Don't Repeat Yourself) approach to coding.

Key Features

• Authentication: The framework provides a robust system for handling API authentication, simplifying the integration of secure and efficient authentication methods into your projects.

• API Construction: This package offers tools to easily define and structure your API interactions, allowing for dynamic and flexible API client creation that adapts to the specific needs of different projects.

• CRUD Class Mixins: The project includes reusable class mixins for building CRUD operations. These mixins promote code reusability and consistency across multiple projects, ensuring that common functionality is implemented efficiently and with minimal duplication.

This framework is designed to help developers focus on implementing the specific logic required for their APIs while relying on a solid, reusable foundation for the underlying infrastructure. It supports a modular approach, making it easier to manage and scale API client development across various projects.

Using Dev Containers

Project uses devcontainers

Run project locally via dev-containers

A development container is a running Docker container with a well-defined tool/runtime stack and its prerequisites.

If you already have VS Code and Docker installed, you can click the badge above to automatically install the Remote - Containers extension if needed, clone the source code into a container volume, and spin up a dev container for use.

If this is your first time using a development container, please ensure your system meets the prerequisites (i.e. have Docker installed) in the getting started steps.

Test out project

Once you have this project opened, you'll be able to work with it like you would locally.

Note that ha bounch of key extentions are allready installed + there is local project settings set up in the background, even though there is no settings.json file. These settings are made to match with developmental team standards.

Note: This container runs as a non-root user with sudo access by default.

Testing and Coverage

Testing and Coverage

This project employs pytest as the primary testing framework to ensure the reliability and correctness of the codebase. pytest is configured to run comprehensive tests across the project, providing detailed feedback on the results, including which tests pass or fail, and offering powerful tools like fixtures and parameterization to create flexible and scalable tests.

Coverage with Coverage.py

The project also integrates coverage.py to measure code coverage during testing. Code coverage analysis helps identify untested parts of the codebase, ensuring that the tests cover as much of the code as possible. This approach enhances the robustness of the code by verifying that all critical paths and edge cases are tested.

The configuration for coverage.py is set up in the .coveragerc file, which specifies which parts of the code should be included or omitted from the coverage report. The generated coverage reports provide insights into the percentage of code that is tested, helping to maintain high standards for test completeness.

The setup is optimized for use within the development container, which forwards a custom port (5051) to serve the live coverage reports, making it easy to view and analyze test coverage in real-time.

Running Tests

To run the tests and generate a coverage report, simply use the following commands within the container:

pytest --cov=your_package_name --cov-report=html

This command will execute all tests and generate an HTML report that you can view in your browser, providing a visual representation of the code coverage.

Pre-Commit and Pre-Push Hooks

Pre-Commit and Pre-Push Hooks

This project integrates pre-commit and pre-push hooks to ensure that code quality is maintained and that all changes meet the project's standards before they are committed or pushed to the repository. These hooks are configured using the .pre-commit-config.yaml file, which specifies the various tools and checks that are automatically run at different stages of the Git workflow.

Pre-Commit Hooks

Pre-commit hooks are executed before each commit is finalized. These hooks ensure that the code adheres to the project's style guidelines and passes initial validation checks. The following tools are configured to run as part of the pre-commit hooks:

• isort: Ensures that imports are properly sorted according to the project's style.
• black: Formats the code to comply with the black code style, with a line length of 120 characters.
• flake8: Runs linting checks to identify any potential issues in the code, excluding setup.py.
• mypy: Performs static type checking to ensure type safety in the codebase.
• pytest: Runs the unit tests to verify that the code changes do not break existing functionality.

These tools are configured to run automatically when you attempt to make a commit, helping to catch errors early and maintain a high standard of code quality.

Pre-Push Hook

The pre-push hook is executed before any changes are pushed to the remote repository. This hook includes an additional layer of testing to ensure that the code meets the required coverage standards:

• pytest with coverage: Runs the full test suite with coverage analysis, ensuring that the codebase meets the required coverage threshold (configured to fail if coverage is below 100%).

By enforcing these checks before pushing, the project ensures that all changes are thoroughly validated, reducing the risk of introducing issues into the main codebase.

Poetry Usage

Poetry Usage

This project leverages Poetry as the primary tool for dependency management, packaging, versioning, and general project configuration. Poetry is a powerful tool that simplifies the entire lifecycle of a Python project, from development to distribution.

Package Management

Poetry is configured to handle all aspects of package management for this project. It allows you to define dependencies clearly in the pyproject.toml file, ensuring that the correct versions of each package are used. Poetry's dependency resolver manages compatibility between packages and installs them in a reproducible environment.

Poetry handles:

• Dependency Resolution: Ensuring that all dependencies and their sub-dependencies are compatible and correctly installed.
• Package Installation: Installing all required dependencies as defined in the pyproject.toml file, ensuring consistency across different environments.

Publishing to PyPI

We use Poetryto publish packages to PyPI through our CI/CD pipeline with GitHub actions / workflows. These workflows automate the process of building, packaging, and publishing the package to PyPI, ensuring that the deployment process is consistent and error-free. See chapter CD/CI for more information.

Versioning

Poetry is used to manage the versioning of the project. Version numbers are specified in the pyproject.toml file and can be automatically updated as part of the release process. We follow semantic versioning practices, where version numbers indicate the nature of changes (major, minor, patch) and help maintain backward compatibility.

Other Uses of Poetry

• Script Management: Poetry allows us to define custom scripts that can be run within the project, streamlining repetitive tasks and ensuring consistency across environments.

• Development Dependencies: Poetry distinguishes between production and development dependencies, ensuring that only the necessary packages are included in the final distribution, keeping it lightweight and efficient.

• Environment Configuration: Although Poetry typically creates a virtual environment (venv) for each project, in this setup, we have configured Poetry to avoid creating virtual environments due to our use of development containers. This ensures that dependencies are installed directly into the container environment, simplifying the setup and avoiding potential conflicts.

This configuration is particularly beneficial in a devcontainer environment, where the container itself acts as the isolated development environment, eliminating the need for a separate virtual environment.

add [skip ci] to commit message to not run github actions for testing