semvec/pypi-packages huggingface dataset:
triton-prep 0.1.0
CLI tool for preparing HuggingFace models for Triton Inference Server.
Requires Python: >=3.12

# triton-prep

`triton-prep` is a lightweight CLI helper for turning HuggingFace *text* models into Triton Inference Server repositories. It focuses on the minimal flow required for encoder/decoder NLP models: inspect → export to ONNX → emit `config.pbtxt` → assemble the repo layout.

> **Note**  
> Only text models are supported in this MVP. Vision/audio architectures or custom preprocessing pipelines are out of scope for now.

## What you get

- Task-aware export to ONNX (feature extraction, classification, causal LM, seq2seq LM).
- Optional FP16 conversion of the exported graph.
- Automatic Triton repository layout creation with tokenizer artifacts.
- Config generator that tailors inputs/outputs/instance groups for text workloads.
- Quick sanity checks: repository validation and ONNX runtime smoke test.

## Requirements

- Python 3.11+
- PyTorch with CPU support (GPU optional)
- `onnx`, `onnxruntime`, `transformers`, `uv` (or your preferred runner)

Install the project in editable mode (example shown with `uv`; replace with `pip` if you prefer):

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

## CLI overview

```plaintext
triton-prep
├── prepare  # inspect HF model, export ONNX, build Triton repo
├── info     # print high-level model metadata
└── check
    ├── repo  # validate Triton repository structure
    └── onnx  # run ONNXRuntime inference with dummy text inputs
```

### Prepare a model

```bash
triton-prep prepare hf-internal-testing/tiny-random-bert \
  --output models \
  --model-name tinybert \
  --opset 18 \
  --max-batch 8 \
  --dynamic \
  --clean
```

This will:

1. Inspect the HuggingFace model to determine the best task type, embeddings dimension, etc.
2. Export the model to ONNX (and FP16 if `--fp16` is set).
3. Generate a Triton config with the requested batch/device settings.
4. Assemble or refresh `models/tinybert` with `config.pbtxt`, versioned model file, and tokenizer assets.

### Inspect model info

```bash
triton-prep info hf-internal-testing/tiny-random-bert
```

Outputs the detected task, parameter count, embedding dimension, and vocabulary size so you can sanity check before export.

### Validate outputs

After preparing a repo you can run:

```bash
triton-prep check repo models/tinybert
triton-prep check onnx models/tinybert/1/model.onnx
```

The first command ensures the repository has the expected layout. The second spins up ONNX Runtime with auto-generated text tensors to make sure the exported graph executes.

## Development

```bash
uv run python -m triton_prep --help
```

Linting is configured through `ruff` and type checking via `mypy`. Feel free to extend the CLI or exporter for additional text tasks—just keep the MVP goal of text-only coverage in mind.
scruff 0.14.6.post2
A scruffier ruff.
Requires Python: >=3.7
Keywords: ruff, automation, flake8, pycodestyle, pyflakes, pylint, clippy

# Scruff

> A scruffier `ruff`.

[**Docs**](https://docs.astral.sh/ruff/) | [**Playground**](https://play.ruff.rs/)

An extremely fast Python linter and code formatter, written in Rust.
mkdocs-changelog-feed-plugin 2025.11.23
MkDocs plugin that adds RSS and Atom feeds for a changelog in the Keep a Changelog format.
Requires Python: <4.0,>=3.10

# MkDocs changelog feed plugin

[MkDocs](https://www.mkdocs.org/) plugin that adds RSS and Atom feeds for a changelog.

This plugin takes the rendered HTML output of the page specified by the [`changelog_file` setting](#changelog_file), splits  it into sections for each changelog entry, and generates RSS and Atom feeds with items for each of those entries. Then, links to the feeds are added to the page.

The page is expected to be in the [Keep a Changelog](https://keepachangelog.com/) format, e.g. every entry starts with a second level heading, the version title and the date have to be separated by -[^dash], the date has to be in ISO 8601 format, etc.

## Installation

```shell
pip install mkdocs-changelog-feed-plugin
```

## Usage

In `mkdocs.yaml`, set `site_url` and add the plugin to `plugins`:  

```yaml
site_name: My Docs
site_url: https://mydocs.example.com/
plugins:
  - search
  - changelog_feed
```

## Plugin configuration

### `changelog_file`

The file within your `docs` directory containing the changelog.

**default**: `CHANGELOG.md`

### `feed_title`

The feed's title.

Defaults to "*page name* - *site name*", if not set.

**default**: `null`

### `feed_description`

The feed's description (RSS)/subtitle (Atom).

**default**: `null`

### `remove_permalinks`

Remove permalinks added by [Python-Markdown's Table of Contents extension](https://python-markdown.github.io/extensions/toc/) from the feeds.

**default**: `true`

### `links_icon`

Icon to be displayed next to the links to the feeds at the top of the page.

**default**: `<i class="fa fa-square-rss"></i>`

## Licence

This project is licenced under the AGPL-3.0 license.

[^dash]: Or &ndash; or &mdash;, in case something like the SmartyPants extension replaces the `-` character.
zdbg 1.1.2
A tiny (nearly) zero-cost debugging helper for Python
Requires Python: >=3.6
Keywords: debug, logging, diagnostics

# zdbg

A (nearly) zero-cost library for printing debugging and error messages from Python programs that is trivial to use, while also giving you the following.

- Per-stream output selection (errors and debugging messages).
- Color-tagged labels.
- Optional timestamps and file context information.
- Zero-cost disable path (via rebinding debug to a no-op).
- Atomic thread-safe reconfiguration.
- Optional stream flush behavior.
- No handler objects, logger objects, format strings, or logger factories.
- A single `configure()` function determining all output behavior.
- NO additional dependencies beyond the standard Python libraries.

How simple is **zdbg** to use? The following is an example.

```python
import zdbg

if __name__ == "__main__":
    zdbg.debug("Starting")
    zdbg.error("Nothing to do")
    zdbg.debug("Stopping")
```

Put the above in `ztest.py` and then try the following.

```bash
$ python3 ./ztest.py
Error: Nothing to do

$ DEBUG=debug python3 ./ztest.py
DEBUG: Starting
Error: Nothing to do
DEBUG: Stopping

$ DEBUG=debug,context python3 ./ztest.py
DEBUG: ./ztest.py:8: Starting
Error: ./ztest.py:9: Nothing to do
DEBUG: ./ztest.py:10: Stopping
```

![Screenshot of shell interaction](https://gitlab.com/sprowell/zdbg/-/raw/main/etc/bash1.png?ref_type=heads)

The format of the error context string makes it clickable in many tools, including Visual Studio Code.

## Why zdbg

I wanted something simple with zero overhead when debugging is disabled, without other dependencies, and with configurability without having to do a lot of work up front to get things working.

If that sounds good, then Welcome!

**zdbg** uses [Semantic Versioning][].

## Performance

"Zero cost?" Well... of course not. But as close to that as I think we can get while still having runtime configurability. See the `perftest.py` script in `examples` for a simple performance test that shows the relative overhead of different debugging strategies.

## Documentation

See the full documentation of **zdbg** in the docstring for the module, or `USAGE.md`

## Bugs?

Have you found a bug? Submit it through the [zdbg Issues][] tracker, and be sure to include (1) what happens, (2) what you _expect_ to happen, (3) how to _reproduce_ the bug, and (4) what _version_ of **zdbg** you are using.

## Minimum Supported Python Version

See `pyproject.toml`.

## Security

Please submit sensitive security issues using the "This issue is confidential..." button below the issue description field in the issue tracker.

## Contribute

See `CONTRIBUTING.md` for information about contributing to this project.

## Copyright

**zdbg** is Copyright (c) by Stacy Prowell <mailto:sprowell+zdbg@gmail.com>. All rights reserved. See the `LICENSE` file for more information.

[zdbg Issues]: https://gitlab.com/sprowell/zdbg/-/issues
[Semantic Versioning]: https://semver.org/