semvec/pypi-packages huggingface dataset:
oslo.reports 3.7.0
oslo.reports library
Requires Python: >=3.10

============
oslo.reports
============

.. image:: https://governance.openstack.org/tc/badges/oslo.reports.svg

.. Change things from this point on

.. image:: https://img.shields.io/pypi/v/oslo.reports.svg
    :target: https://pypi.org/project/oslo.reports/
    :alt: Latest Version

.. image:: https://img.shields.io/pypi/dm/oslo.reports.svg
    :target: https://pypi.org/project/oslo.reports/
    :alt: Downloads

When things go wrong in (production) deployments of OpenStack collecting debug
data is a key first step in the process of triaging & ultimately resolving the
problem. Projects like Nova has extensively used logging capabilities which
produce a vast amount of data. This does not, however, enable an admin to
obtain an accurate view on the current live state of the system. For example,
what threads are running, what config parameters are in effect, and more.

The project oslo.reports hosts a general purpose error report generation
framework, known as the "guru meditation report"
(cf http://en.wikipedia.org/wiki/Guru_Meditation) to address the issues
described above.

Models: These classes define structured data for a variety of interesting
pieces of state. For example, stack traces, threads, config parameters,
package version info, etc. They are capable of being serialized to XML / JSON
or a plain text representation

Generators: These classes are used to populate the model classes with the
current runtime state of the system

Views: views serialize models into say JSON, text or xml. There is also
a predefined view that utilizes Jinja templating system.

There will be a number of standard models / generators available for all
OpenStack services

StackTraceModel: a base class for any model which includes a stack trace
ThreadModel: a class for information about a thread
ExceptionModel: a class for information about a caught exception
ConfigModel: a class for information about configuration file settings
PackageModel: a class for information about vendor/product/version/package information

Each OpenStack project will have the ability to register further generator
classes to provide custom project specific data.

* Free software: Apache license
* Documentation: https://docs.openstack.org/oslo.reports/latest
* Source: https://opendev.org/openstack/oslo.reports
* Bugs: https://bugs.launchpad.net/oslo.reports
* Release notes: https://docs.openstack.org/releasenotes/oslo.reports/
gittoolfetcher 1.2.1
A git management tool, making it easy to install and use multiple concurent version of a same project.
Requires Python: >=3.10

# GitToolFetcher

GitToolFetcher is a tool to help managing multiple concurent versions of GitHub hosted projects.

## How to install

To install GitToolFetcher, we recommend pulling directly from PyPi :

```bash
pip install gittoolfetcher
```

This will install GitToolFetcher as well as its necessary dependencies.

### Building from source

If you wish to build & install GitToolFetcher from source instead, use Hatch's usual build command :

```bash
hatch build
```

The built archive will be placed in the "dist" directory as a .whl file.
To install GitToolFetcher, simply install the .whl file using pip.

```bash
pip install dist/gittoolfetcher-*.whl
```

## Command Line Usage

Once installed, a new utility `gittoolfetcher` will be available.

```
usage: gittoolfetcher [-h] [-r] [-s] [-i [INSTALL ...]] [-u [UNINSTALL ...]] [-v VERSION] [-l] [-e COMMAND] REPO_NAME

positional arguments:
  REPO_NAME             Name of the GitHub repo to manage.

options:
  -h, --help                                       show this help message and exit
  -r, --refresh                                    Refresh the available version cache.
  -s, --show                                       Show available project versions.
  -i [INSTALL ...], --install [INSTALL ...]        Install one or more project versions.
  -u [UNINSTALL ...], --uninstall [UNINSTALL ...]  Uninstall one or more project versions.
  -v [VERSION ...], --version [VERSION ...]        Select a version of the project.
  -l, --list                                       List installed project versions.
  -e COMMAND, --execute COMMAND                    Execute a command with the selected version of the project.
```

Here is a typical workflow using GitToolFetcher :

```bash
gittoolfetcher golang/go -r -s -i go1.14,go1.6,go1.23.4 -l
```
pypepper 0.4.1
PyPepper is a microservice toolkit written in Python.
Requires Python: >=3.10

<div align="center">

![logo](docs/logo/logo.svg)

</div>

# PyPepper

[![PyPI](https://img.shields.io/pypi/v/pypepper?label=\&logo=pypi\&logoColor=fff)](https://pypi.org/project/pypepper/)
[![GitHub Actions](https://github.com/jovijovi/pypepper/workflows/Test/badge.svg)](https://github.com/jovijovi/pypepper)
[![Coverage](https://img.shields.io/codecov/c/github/jovijovi/pypepper?label=\&logo=codecov\&logoColor=fff)](https://codecov.io/gh/jovijovi/pypepper)

> _In memory of my father, who passed away in 2023 from COVID-19._

PyPepper is a microservice toolkit.

<https://github.com/jovijovi/pypepper>

## :checkered_flag: Features

### ***common***

Common packages.

- `context`
  - `common.context` A powerful chained context
- `security`
  - `common.security.crypto.elliptic.ecdsa` Sign/Verify message by ECDSA
  - `common.security.crypto.digest` Get hash bytes/hex
  - `common.security.crypto.salt` Generates a random salt of the specified size
- `utils`
  - `common.utils.random` A class for generating random values
  - `common.utils.retry` Retry running the function by random interval, support lambda
  - `common.utils.time` Get UTC/local datetime/timezone/timestamp, support sleep
  - `common.utils.uuid` UUID(v4) generator
- `cache`
  - `common.cache` A thread safe TTL cache-set
- `log`
  - `common.log` A simple logger based on [loguru](https://github.com/Delgan/loguru)
- `options`
  - `common.options` An easy-to-use options
- `system`
  - `common.system` System signals handler

### ***event***

An event package with payload, support sign/verify signature.

### ***fsm***

An out-of-box FSM with event trigger, support custom state.

### ***helper***

Database helper.

- `helper.db.mongodb` MongoDB helper
- `helper.db.mysql` MySQL helper

### ***network***

- `network.http` RESTFul API server based on [FastAPI](https://github.com/tiangolo/fastapi). 

### ***scheduler***

A Workflow-based job scheduler.

### ***loader***

Module loader.

## :computer: Quick Guide

- Development Environment
  - python `3.10`,`3.11`,`3.12`,`3.13`,`3.14`
  - uv >= `0.9.0`

- Build code

  Install all dependencies and compile code.

  ```shell
  make build
  ```

- Test with coverage

  ```shell
  make test
  ```

- Build docker image

  ```shell
  make docker
  ```

- Clean

  ```shell
  make clean
  ```

## :bulb: Roadmap

- [ ] Documents
- [ ] Tracing
phonexia-voiceprint-extraction-client 2.0.1
Client for communication with Phonexia voiceprint extraction microservice.
Requires Python: >=3.9
Keywords: grpc, voice, voice-biometry, speech, language, identification

![](https://www.phonexia.com/wp-content/uploads/phonexia-logo-transparent-500px.png)

# Phonexia voiceprint extraction client

This module contains client for communication with [voiceprint extraction microservice](https://hub.docker.com/repository/docker/phonexia/voiceprint-extraction/general) developed by [Phonexia](https://phonexia.com).

To use this client you will first need a running instance of any *Phonexia voiceprint extraction microservice*. If you don't yet have any running instance, don't hesitate to [contact our sales department](mailto:info@phonexia.com).

You can learn more about the speaker identification technology [here](https://docs.phonexia.com/products/speech-platform-4/technologies/speaker-identification/).

On [this page](https://docs.phonexia.com/products/speech-platform-4/grpc/api/phonexia/grpc/technologies/speaker_identification/v1/speaker_identification.proto#voiceprintextraction), you will find a *gRPC API* reference for *voiceprint extraction microservice*.
ecs-logging 2.3.0
Logging formatters for ECS (Elastic Common Schema) in Python
Requires Python: >=3.8

# ecs-logging-python

[![Build Status](https://github.com/elastic/ecs-logging-python/actions/workflows/test.yml/badge.svg)](https://github.com/elastic/ecs-logging-pythonactions/workflows/test.yml)
[![PyPI](https://img.shields.io/pypi/v/ecs-logging)](https://pypi.org/project/ecs-logging)
[![Versions Supported](https://img.shields.io/pypi/pyversions/ecs-logging)](https://pypi.org/project/ecs-logging)

Check out the [Elastic Common Schema (ECS) reference](https://www.elastic.co/guide/en/ecs/current/index.html)
for more information.

The library currently implements ECS 1.6.

## Installation

```console
$ python -m pip install ecs-logging
```

## Documentation

See the [ECS Logging Python reference](https://www.elastic.co/guide/en/ecs-logging/python/current/index.html) on elastic.co to get started.

## Elastic APM Log Correlation

`ecs-logging-python` supports automatically collecting [ECS tracing fields](https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html)
from the [Elastic APM Python agent](https://github.com/elastic/apm-agent-python) in order to
[correlate logs to spans, transactions and traces](https://www.elastic.co/guide/en/apm/agent/python/current/log-correlation.html) in Elastic APM.

## License

Apache-2.0
microservice-chassis-grupo2 0.0.0
A reusable library for microservices
Requires Python: >=3.10

# 🧩 Microservice Chassis Grupo 2

**Repository link:** https://github.com/Grupo-MACC/Chassis

---

## Functionalities

This repository provides a **shared chassis** for microservices, containing configuration, database management, authentication, messaging, and helper utilities.  
It allows microservices to reuse common functionalities such as database connections, JWT validation, RabbitMQ communication, and standardized base models.

Below is a detailed list of the available functionalities:

| **Module** | **Functionality** | **Description** |
|-------------|------------------|-----------------|
| `core/config.py` | **Settings Management** | Centralized configuration for the chassis. Defines constants like the encryption algorithm (`RS256`), RabbitMQ connection parameters (`RABBITMQ_HOST`), and exchange name (`broker`). |
| `core/security.py` | **Token Decoding and Verification** | Handles JWT decoding using a public RSA key. Validates tokens and raises appropriate HTTP errors if invalid or missing. |
| `core/dependencies.py` | **Database Session & Authentication Dependency** | Provides FastAPI dependencies to manage asynchronous database sessions (`get_db`) and current user retrieval (`get_current_user`) from a JWT token. |
| `core/rabbitmq.py` | **RabbitMQ Channel & Exchange Management** | Creates asynchronous connections to RabbitMQ using `aio_pika`. Declares durable topic exchanges for inter-service communication. |
| `core/utils.py` | **Helper Functions and Service URLs** | Defines service URLs (order, machine, delivery, payment, auth) and provides error handling utilities with standardized logging (`raise_and_log_error`). |
| `sql/database.py` | **Database Engine & Session Configuration** | Configures SQLAlchemy’s asynchronous engine and sessionmaker. Supports `SQLALCHEMY_DATABASE_URL` via environment variable (defaults to SQLite). |
| `sql/base_class.py` | **Base Model for ORM Classes** | Provides a reusable abstract base class (`BaseModel`) for all database models, including timestamp columns (`creation_date`, `update_date`) and helper methods for converting models to dictionaries. |

---

## Functionalities per Microservice

| **Microservice** | **Used Functionalities** |
|------------------|--------------------------|
| `payment` | `core/config`, `core/security`, `core/dependencies`, `core/rabbitmq`, `core/utils`, `sql/database`, `sql/base_class` |

---

## Summary

This chassis allows the `payment` microservice (and potentially others in the future) to operate with consistent patterns for:
- Secure token validation.
- Standardized database access and sessions.
- Centralized configuration.
- RabbitMQ-based inter-service communication.
- Common helper utilities and error management.
- Unified base ORM models.

It provides a robust foundation for building scalable and maintainable microservices within the system.
mal-gui 2.0.0
A graphical user interface tool used to create MAL instance models.
Requires Python: <=3.13,>=3.10

# mal-toolbox-gui
A graphical user interface tool used to create MAL instance models and scenarios (with attacker agents specified).

## Installation

Install the package from pypi by running `pip install mal-gui`.

## Run

If you have installed the package locally you can run the command `malgui` to run the GUI.

This will open up the graphical user interface.

If you for any reason don't want to install the package, you can run it as a module directly with `python -m mal_gui.app` from this directory.


## How to use the graphical interface

### Starting up

![Start popup](docs/select_lang.png "Select MAL/MAR archive.")

When you start up `malgui` you need to select a MAL-language.

Read the tutorial if you do not know how: https://github.com/mal-lang/mal-toolbox-tutorial.

### Add an asset
When you have started the application you can drag and drop new assets from the object explorer on the left.

### Create associations
To create associations you use SHIFT + Left click to drack and drop between two assets. This lets you select what association they should have.
Same goes for attacker entry points.

![Overview of the MAL gui](docs/overview.png "Info on how to do things in malgui.")

### Remove an asset
To remove an asset, click it and press delete key on your keyboard or the Delete button in the top bar.
Alternatively, you can also right click and click 'Delete Asset'.

### Remove an association
To remove an association, right click the association name/label and select 'Delete connection'. Same goes for attacker entry points.

![Delete association](docs/remove_assoc.gif "Info on how to delete an assocation.")