semvec/pypi-packages huggingface dataset:
lazy-wheels 0.1.9
Lazy monorepo wheel builder — only rebuilds what changed.
Requires Python: >=3.11

# lazy-wheels

CI release workflow for your multi-package uv monorepo that only rebuilds changed packages.

## Why lazy-wheels?

Managing versions across multiple packages in a monorepo is painful. `lazy-wheels` makes it simple: **you own major.minor, CI owns patch**. When you're ready for a breaking change or new feature in any package, bump the major or minor version yourself (e.g. `uv version --project packages/your-project --bump minor`). For everything else, CI automatically increments patch versions after each release.

`lazy-wheels` always keeps your `main` branch one patch version ahead of the latest release (i.e. `main` represents _unreleased_ changes). This means HEAD is always releasable, version numbers are always increasing, and you never have to think about patch versions again. Change detection uses per-package git tags, so only packages with actual changes (or dependencies on changed packages) get rebuilt.

## Installation

```bash
pip install lazy-wheels
```

Or with uv:

```bash
uv add --group dev lazy-wheels
```

Or scaffold just once with uvx:

```bash
uvx lazy-wheels init
```

## Usage

### Initialize

Scaffold the GitHub Actions workflow into your repo:

```bash
lazy-wheels init
```

This creates `.github/workflows/release.yml` configured for your uv workspace.

**Requirements:**
- A git repository
- A `pyproject.toml` with `[tool.uv.workspace]` members defined

### Triggering a Release

**Option 1: GitHub CLI**

```bash
gh workflow run release.yml
gh workflow run release.yml -f release=r1
gh workflow run release.yml -f force_rebuild_all=true
```

**Option 2: lazy-wheels CLI**

Just wraps the `gh` commands into a more compact CLI.

```bash
lazy-wheels release
lazy-wheels release -r r1
lazy-wheels release --force-all
```

**Option 3: GitHub.com**

You can also manually launch the `release` workflow in the github.com UI.

### Workflow Inputs

| Input | Description |
|-------|-------------|
| `release` | Release tag (e.g., `r1`, `r2`). Auto-generates if not provided. |
| `force_rebuild_all` | Rebuild all packages regardless of changes. |

## How It Works

1. **Discover** — Scans `[tool.uv.workspace]` members to find all packages and their dependencies
2. **Detect changes** — Compares each package against its last release tag (`{pkg}/v{version}`)
3. **Propagate dirtiness** — Marks dependents of changed packages as dirty (transitive rebuild)
4. **Fetch unchanged** — Downloads wheels for unchanged packages from previous GitHub releases
5. **Build changed** — Runs `uv build` only on packages that need rebuilding
6. **Tag** — Creates per-package version tags (e.g., `my-pkg/v1.2.3`)
7. **Bump versions** — Increments patch version in each built package's `pyproject.toml`
8. **Publish** — Creates a GitHub Release with all wheels (changed + unchanged)
9. **Push** — Commits version bumps and pushes tags
llama-index-utils-workflow 0.9.2
llama-index utils for workflows
Requires Python: >=3.9

# LlamaIndex Utils: Workflow

Utilities for LlamaIndex workflows, including visualization tools.

```bash
pip install llama-index-utils-workflow
```

## Features

- **Workflow visualization** with `draw_all_possible_flows()`
- **Latest execution visualization** with `draw_most_recent_execution()`
- **Label truncation support** for better readability with long event names

## Usage

```python
from llama_index.utils.workflow import draw_all_possible_flows

# Basic workflow visualization
draw_all_possible_flows(my_workflow, "workflow.html")

# With label truncation for long event names (v0.4.0+)
draw_all_possible_flows(my_workflow, "workflow.html", max_label_length=15)

# Latest execution visualization
handler = my_workflow.run()
await handler
draw_most_recent_execution(handler, "workflow.html")
```
phys-sims-utils 0.2.0
Shared research infrastructure for deterministic experimentation
Requires Python: >=3.10

# phys-sims-utils

Shared research infrastructure for deterministic experimentation.

## Agent tooling quick answers

If you are evaluating the agent layer, start here: `docs/how-to-use-agents.md`.

It answers:

- how agents are used in this repo,
- whether MCP is required (it is optional), and
- what UX is available today for non-coding users.

## Optional dependency extras

Install only the surfaces you need:

- `pip install phys-sims-utils[harness]`
- `pip install phys-sims-utils[ml]`
- `pip install phys-sims-utils[agent]`
- `pip install phys-sims-utils[all]`

`phys-sims-utils[ml]` now includes optional optimizer dependencies used by built-in strategies:

- `scipy` for `SobolStrategy`
- `cma` for `CMAESStrategy`

If you only need CMA-ES support in an existing environment, install:

- `pip install cma`

## CMA-ES usage

```python
from phys_sims_utils.ml import Parameter, ParameterSpace
from phys_sims_utils.ml.strategies import CMAESStrategy

space = ParameterSpace(
    parameters=(
        Parameter("x", bounds=(-1.0, 1.0)),
        Parameter("y", bounds=(0.0, 5.0)),
    )
)

strategy = CMAESStrategy(parameter_space=space, seed=42)
candidate = strategy.ask()
# ... evaluate objective(candidate.theta) ...
```

`CMAESStrategy` is deterministic for the same parameter space and seed, enforces parameter
bounds for generated candidates, and raises an actionable `RuntimeError` at construction time if
`cma` is not installed.

`phys-pipeline` remains optional and adapter-scoped. Core modules in `phys_sims_utils.harness`,
`phys_sims_utils.ml`, and `phys_sims_utils.agents` must not require `phys-pipeline`; direct imports
are restricted to `phys_sims_utils.harness.adapters.phys_pipeline`.