Skip to main content
 █████╗ ███████╗████████╗ ██████╗ ███╗   ██╗
██╔══██╗██╔════╝╚══██╔══╝██╔═══██╗████╗  ██║
███████║███████╗   ██║   ██║   ██║██╔██╗ ██║
██╔══██║╚════██║   ██║   ██║   ██║██║╚██╗██║
██║  ██║███████║   ██║   ╚██████╔╝██║ ╚████║
╚═╝  ╚═╝╚══════╝   ╚═╝    ╚═════╝ ╚═╝  ╚═══╝

 ██████╗██╗     ██╗
██╔════╝██║     ██║
██║     ██║     ██║
██║     ██║     ██║
╚██████╗███████╗██║
 ╚═════╝╚══════╝╚═╝

https://github.com/user-attachments/assets/812a1990-13c3-4c45-8a8e-080f602c7a3f

Automated dependency migration, from breaking-change detection to a verified pull request.

PyPI Python Docker GitHub PRs Status

Quick Start • Live Demo • How It Works • Commands • Architecture • FAQ • Contributing

Making dependency migrations less manual.


Table of Contents

Click to expand
  1. The problem ASTon solves
  2. Quick start
  3. ASTon migration demonstration
  4. How it works
  5. The 10 stages in detail
  6. Command reference
  7. Run the complete workflow
  8. Example migration
  9. Project architecture
  10. Generated files and directories
  11. Installation
  12. Design principles
  13. Current scope & roadmap
  14. FAQ & troubleshooting
  15. Contributing

The problem ASTon solves

Your project uses an older version of a Python library. A new version ships and some APIs change.

# Old API
import openai

openai.ChatCompletion.create(...)
# New API
from openai import OpenAI

client = OpenAI()
client.chat.completions.create(...)

Simply bumping the version can break your app. Traditionally you would have to:

  1. Read release notes and migration guides
  2. Find the breaking changes relevant to your code
  3. Search your codebase for affected APIs
  4. Rewrite the affected code
  5. Run tests and debug failures
  6. Commit and open a pull request

ASTon automates that entire loop and hands you a reviewable PR.


Quick start

Three commands, from update detection to pull request:

aston watcher --path demo          # 1. detect dependency updates
aston check --run --path demo      # 2. run the migration pipeline
aston pr --path aston/succ_migrations --repo demo   # 3. open the PR

Not sure what's available? Run aston --help or aston <command> --help at any time.

Prerequisites checklist
  • Python installed
  • Docker installed and running
  • Git installed
  • GitHub access (for PR creation)
  • API key for your configured LLM provider
  • A local clone of the target repository (e.g. demo/)

ASTon Migration Demonstration

This repository demonstrates ASTon's end-to-end dependency migration workflow using a Python application built with the legacy OpenAI Python SDK.

ASTon analyzed the repository, identified deprecated API usage across multiple Python modules, generated migration changes, verified the updated code, and submitted a GitHub pull request that was subsequently merged.

The demo recording is at the top of this README.

Migration details

  • Source dependency: openai==0.28.1
  • Target dependency: openai==3.41.0
  • Migration scope: Multiple Python modules
  • Verification: Docker-based verification and repository-wide tests

Migration evidence

Artifact Link
Original legacy code Initial commit
ASTon-generated changes Migration commit
Merged migration Merge commit
Complete code comparison View before-and-after diff
ASTon source code GitHub repository

What this demonstrates

  1. Breaking-change discovery from dependency documentation.
  2. Identification of affected code across multiple modules.
  3. Automated migration rule generation and code modification.
  4. Docker-based verification and repository-wide testing.
  5. GitHub pull request creation and merging.
Reproduce this demo

Clone the demo project next to ASTon and run the same three commands from the quick start:

git clone https://github.com/2022n02511-stack/demo_aston.git demo

aston watcher --path demo
aston check --run --path demo
aston pr --path aston/succ_migrations --repo demo

The demo project starts on the legacy openai==0.28.1 code, so it shows the same before-and-after the links above describe.

Note: This is a demonstration project designed to showcase ASTon's migration capabilities, not a production customer deployment.


How it works

The 30-second view

 ┌──────────────────────────────────────────────────────────────────────────┐
 │                         ASTon  MIGRATION PIPELINE                        │
 └──────────────────────────────────────────────────────────────────────────┘

   ① WATCH        ② INGEST         ③ EXTRACT        ④ SCAN
 ┌─────────┐    ┌───────────┐    ┌────────────┐    ┌────────────┐
 │ new pkg │───▶│ changelog │───▶│ LLM builds │───▶│ AST usage  │
 │ version │    │ + guides  │    │ rules.json │    │ map of repo│
 └─────────┘    └───────────┘    └────────────┘    └─────┬──────┘
                                                          │
   ⑧ VERIFY       ⑦ GENERATE       ⑥ VALIDATE       ⑤ RELEVANCE
 ┌──────────┐   ┌────────────┐   ┌────────────┐   ┌──────┴──────┐
 │ Docker   │◀──│ candidate  │◀──│ rules vs   │◀──│ which rules │
 │ per file │   │ migrations │   │ target ver │   │ hit my code?│
 └────┬─────┘   └────────────┘   └────────────┘   └─────────────┘
      │
      ├── fail ──▶ REPAIR ──▶ (back to ⑧)
      │
      └── pass
            │
            ▼
   ⑨ FULL-REPO VERIFY              ⑩ DELIVER
 ┌─────────────────────┐        ┌──────────────────────┐
 │ syntax + test cmd   │──pass─▶│ branch → commit →    │──▶ Human review
 │ on combined project │        │ push → GitHub PR     │       & merge
 └──────────┬──────────┘        └──────────────────────┘
            │
          fail
            ▼
     Verification report

The full workflow (Mermaid)

View the complete migration workflow
flowchart TD
    A["Start ASTon"] --> B["Watch for dependency updates"]
    B --> C["Discover new package version"]
    C --> D["Collect release notes and migration documentation"]
    D --> E["Extract migration rules"]
    E --> F["Build repository usage map"]
    F --> G["Identify relevant breaking changes"]
    G --> H["Validate migration rules"]
    H --> I["Generate code migrations"]
    I --> J["Verify individual files in Docker"]
    J --> K{"Migration successful?"}
    K -->|No| L["Repair failed migration"]
    L --> J
    K -->|Yes| M["Save migrated files"]
    M --> N["Verify complete repository"]
    N --> O{"Repository verification passed?"}
    O -->|No| P["Report verification failure"]
    O -->|Yes| Q["Create GitHub pull request"]

Which CLI command runs which stages?

Command Stages it drives Output
aston watcher ① Dependency monitoring Detected updates, version state
aston check --run ②–⑨ Ingest → extract → scan → relevance → validate → generate → verify → repair → full-repo verify succ_migrations/, final_reports/
aston pr ⑩ Pull request creation A GitHub PR for review
 aston watcher ───▶ aston check --run ───▶ aston pr
   (stage 1)          (stages 2 – 9)        (stage 10)

The 10 stages in detail

Click any stage to expand it.

① Dependency monitoring — find out when a dependency has a newer version

ASTon includes a watcher that monitors dependencies and identifies available updates.

Current dependency: openai==0.28.1
Available version:  3.41.0

It also keeps version-related state so previously processed updates can be tracked.

Run it:

aston watcher --path demo
② Change discovery & documentation ingestion — understand what changed

When an update is detected, ASTon collects:

  • Release notes
  • Changelogs
  • Migration guides
  • Relevant documentation links
  • Breaking-change discussions and references

It follows relevant links to gather extra migration context, so extraction doesn't rely on version numbers alone.

flowchart TD
    A["New package version"] --> B["Find release information"]
    B --> C["Collect changelog"]
    C --> D["Find migration documentation"]
    D --> E["Follow relevant documentation links"]
    E --> F["Combine collected information"]
    F --> G["Documentation for rule extraction"]
③ Migration rule extraction — turn docs into structured rules

Documentation is written for humans. ASTon uses an LLM to convert it into structured migration rules:

{
  "package": "openai",
  "old_api": "openai.ChatCompletion.create",
  "new_api": "client.chat.completions.create",
  "migration_type": "rename"
}

Rules can describe:

  • API renames
  • Removed APIs
  • Configuration changes
  • New instantiation requirements
  • Changes in how an API is accessed

Extracted rules are not automatically assumed to be applicable. They are evaluated against the target version first.

④ Repository scanning & usage mapping — see how your project really uses the library

ASTon uses Python's Abstract Syntax Tree (AST) instead of plain text search.

from openai import OpenAI as Client

client = Client()

response = client.chat.completions.create(
    model="example-model",
    messages=[]
)

The scanner captures: imported package, imported symbol, local alias, instantiated objects, API usage, source line, and relevant keyword arguments.

flowchart TD
    A["Python source files"] --> B["Python AST parser"]
    B --> C["Inspect imports"]
    B --> D["Inspect function calls"]
    B --> E["Inspect object instantiation"]
    C --> F["Usage map"]
    D --> F
    E --> F
    F --> G["Repository dependency usage"]
⑤ Change relevance analysis — keep only the rules that matter to you

A library can introduce hundreds of changes. Most won't touch your code.

Extracted change Used in project?
ChatCompletion.create changed Yes
Embedding.create changed Yes
An unrelated API was removed No

The result is a smaller set of potentially relevant migration rules.

⑥ Migration rule validation — don't apply stale rules

A rule that was valid for an earlier upgrade may not be valid for a later one.

Version 0 → Version 1      API A → API B
Version 1 → Version 2      API B → API C

Applying the first rule directly to a project targeting Version 2 would leave it on an outdated API. ASTon validates rules against the target version before code generation.

Rules that can't be validated are not silently treated as confirmed. They remain unresolved for further analysis.

⑦ Code migration generation — produce candidate code
# Before
import openai

response = openai.ChatCompletion.create(...)
# After
from openai import OpenAI

client = OpenAI()
response = client.chat.completions.create(...)

The output is a candidate, not an accepted result. It must pass verification.

⑧ Individual file verification & repair — Docker-isolated checks

Each migrated file is verified inside a Docker container with the target dependency installed. Verification distinguishes between:

  • Successful migrations
  • Migration errors
  • Environment / dependency installation errors
  • External service errors
  • Timeouts
flowchart TD
    A["Generated candidate"] --> B["Create Docker environment"]
    B --> C["Install target requirements"]
    C --> D["Run verification"]
    D --> E{"Passed?"}
    E -->|Yes| F["Save successful migration"]
    E -->|No| G["Analyze verification error"]
    G --> H["Generate repaired candidate"]
    H --> B

Repair process: the failed candidate plus its real verification feedback are used to attempt a better migration, not just repeat the same replacement. Successful files are saved to the migration output directory.

⑨ Full-repository verification — make sure it all works together

Passing per-file checks doesn't guarantee the whole project works (one migrated file may depend on another).

The verification environment combines:

  • Original repository files that were not migrated
  • Successfully migrated files
  • Updated target requirements

Then it runs Python syntax checks and the configured test command.

flowchart TD
    A["Original repository"] --> C["Build verification copy"]
    B["Successful migrated files"] --> C
    D["Target requirements"] --> C
    C --> E["Install dependencies"]
    E --> F["Check Python syntax"]
    F --> G["Run repository tests"]
    G --> H{"Passed?"}
    H -->|Yes| I["Ready for pull request"]
    H -->|No| J["Report verification failure"]
⑩ GitHub pull request creation — reviewable delivery

The PR contains the migrated files and updated dependency requirements. The original source repository is kept separate from ASTon's output during migration, so you stay in control.

flowchart TD
    A["Verified migration output"] --> B["Prepare migration branch"]
    B --> C["Copy migrated files"]
    C --> D["Commit changes"]
    D --> E["Push branch"]
    E --> F["Create GitHub pull request"]
    F --> G["Developer reviews changes"]
    G --> H["Merge when approved"]

Command reference

1. Check available commands

aston --help

2. Start the dependency watcher

aston watcher --path demo

View watcher-specific options:

aston watcher --help

3. Run the migration pipeline

aston check --run --path demo

View migration command options:

aston check --help

4. Create a GitHub pull request

aston pr \
  --path aston/succ_migrations \
  --repo demo \
  --branch demo_aston \
  --title "Migrate OpenAI dependency" \
  --body "Automated dependency migration generated and verified by ASTon."

View PR command options:

aston pr --help
What do the flags mean?
Command Flag Meaning
aston watcher --path Path to the project whose dependencies are monitored
aston check --run Execute the migration pipeline
aston check --path Path to the project to analyze and migrate
aston pr --path ASTon's successful migration output (e.g. aston/succ_migrations)
aston pr --repo Local clone of the target GitHub repository
aston pr --branch Name of the migration branch (optional)
aston pr --title Pull request title
aston pr --body Pull request description

Options can vary between versions. Always confirm with aston <command> --help.


Run the complete workflow

Chain everything in one go. Each command runs only if the previous one succeeds (&&).

aston watcher --path demo && \
aston check --run --path demo && \
aston pr \
  --path aston/succ_migrations \
  --repo demo \
  --branch demo_aston \
  --title "Migrate OpenAI dependency" \
  --body "Automated dependency migration generated and verified by ASTon."
 ┌──────────────┐  ok   ┌──────────────────┐  ok   ┌────────────┐
 │ aston watcher│──────▶│ aston check --run│──────▶│  aston pr  │──▶ PR opened
 └──────┬───────┘       └────────┬─────────┘       └─────┬──────┘
        │ fail                   │ fail                  │ fail
        ▼                        ▼                       ▼
      stop                     stop                    stop

Example migration

This is the migration shown in the demonstration above.

Your project uses:

openai==0.28.1

You want to move to:

openai==3.41.0
flowchart TD
    A["openai 0.28.1"] --> B["Discover target 3.41.0"]
    B --> C["Collect migration documentation"]
    C --> D["Extract API migration rules"]
    D --> E["Scan project for OpenAI usage"]
    E --> F["Identify relevant rules"]
    F --> G["Validate rules for 3.41.0"]
    G --> H["Generate migrated Python files"]
    H --> I["Verify and repair"]
    I --> J["Verify complete repository"]
    J --> K["Create pull request"]

Instead of manually hunting down every affected API, you receive a pull request with the proposed changes.


Project architecture

Main modules
Module Responsibility
watcher.py Monitors dependency updates
poller.py Supports checking for available updates
ingestion.py Collects release and migration documentation
changes/chain.py Handles migration boundaries across versions
axios.py Code-generation and related integration logic
scanner.py Analyzes Python source code and dependency usage
relevance.py Evaluates whether changes affect the repository
rule_validation.py Validates migration rules against the target
pipeline.py Coordinates migration and repair operations
docker.py Verifies individual migrated files
repo_verification.py Verifies the complete migrated repository
repo_index/repo_map.py Maps the repository and coordinates repository migration
github_integrations/pr.py Creates GitHub pull requests
cli/main.py Defines the command-line interface
cli/console.py Provides CLI messages and output
cli_ui/rich.py Provides the Rich terminal interface
Module → pipeline map
 WATCH      watcher.py ── poller.py
   │
 INGEST     ingestion.py ── changes/chain.py
   │
 EXTRACT    axios.py (LLM) ──▶ rules.json
   │
 SCAN       scanner.py ──▶ repo_index/repo_map.py ──▶ repo_index.json
   │
 FILTER     relevance.py ── rule_validation.py
   │
 MIGRATE    pipeline.py ◀──▶ docker.py   (generate ⇄ verify ⇄ repair)
   │
 VERIFY     repo_verification.py
   │
 DELIVER    github_integrations/pr.py

 INTERFACE  cli/main.py ── cli/console.py ── cli_ui/rich.py

Generated files and directories

Path Purpose
artifacts/runs/ Individual migration run artifacts and attempts
succ_migrations/ Successfully migrated files and target requirements
final_reports/ Migration analysis and result reports
rule_cache/ Cached migration-rule information
repo_index.json Repository indexing information
migrations.json Migration-related information
changes.json Collected change information
rules.json Extracted migration rules
temp_requirements.txt Temporary target requirements used during migration

Installation

pip install astoncli
aston --help

The package is named astoncli on PyPI, and the command it installs is aston.

From source

# 1. Clone
git clone https://github.com/2022n02511-stack/ASTon.git
cd ASTon

# 2. Install the project
pip install -e .

# 3. Install dependencies if needed
pip install -r requirements.txt

# 4. Verify the CLI works
aston --help

Then configure the environment variables required by your selected LLM provider and GitHub integration. A template is provided in .env.example.

External requirements: Docker must be installed and running, and you need an API key for your LLM provider and a GitHub token for pull requests. Installing the package does not provide these.


Design principles

# Principle Idea
1 Documentation-driven migration Decisions come from real release notes and migration docs
2 Repository-aware changes Only changes relevant to your usage are considered
3 Version-aware validation Rules must be compatible with the requested target version
4 Verification before acceptance Generated code is tested, not trusted because it looks right
5 Isolated execution Docker isolates dependency installs and verification
6 Reviewable delivery Migrations arrive as PRs so you control what merges

Current scope & roadmap

ASTon is under active development. The current implementation focuses on Python dependency migrations, with the OpenAI Python SDK as the test case demonstrated above. It has been run end to end on one demo project so far.

The architecture separates ingestion, rule extraction, repository analysis, code generation, verification, and delivery, so more packages can be supported without tying the system to one library.

  • Dependency watching
  • Documentation ingestion & rule extraction
  • AST-based repository usage mapping
  • Docker-isolated per-file verification with repair
  • Full-repository verification
  • GitHub pull request creation
  • Version-aware rule validation across more version chains (in progress)
  • Reliability across more real-world repositories
  • Support for additional Python packages
  • pip install astoncli distribution
  • Broader language ecosystem support

FAQ & troubleshooting

Does ASTon change my repository directly?

No. Migration output is kept separate (in succ_migrations/) and only reaches your repo as a pull request that you review and merge.

Why is a rule "unresolved"?

Rules that can't be validated against the target version are never silently treated as confirmed. They stay unresolved so they can be analyzed further instead of risking an incorrect migration.

A file failed verification. What now?

ASTon sends it through the repair loop, using the real failure output to generate a corrected candidate. Check artifacts/runs/ for each attempt and final_reports/ for the result.

Verification failed on dependency installation or timeout.

ASTon separates environment, external-service, and timeout failures from true migration errors. Confirm that Docker is running and has network access, then re-run aston check --run --path demo.

The full-repository check failed even though every file passed.

Individual success doesn't guarantee cross-file compatibility. Review the verification report in final_reports/ to see whether syntax checks or your configured test command failed.

The aston pr command can't push or create the PR.

Check that:

  • --repo points to a valid local clone of the target repository
  • Your GitHub credentials/environment variables are configured
  • --path points to aston/succ_migrations (the successful migration output)
  • You have push access to the repository
A command or flag isn't recognized.

Flags can differ between versions. Run aston --help and aston <command> --help to see what your installed version supports.


Contributing

Contributions, feedback, and ideas are welcome!

If you hit a migration issue, please include:

  • The dependency and source version
  • The target version
  • The affected code
  • The migration report or verification output

These details make problems far easier to reproduce and investigate.


ASTon — Making dependency migrations less manual.

If ASTon saves you time, consider starring the repo.

Metadata

Release files for astoncli 0.1.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for astoncli 0.1.1
File Size Uploaded Provenance Actions
astoncli-0.1.1.tar.gz 58.5 kB Without provenance Details for astoncli-0.1.1.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for astoncli 0.1.1
File Interpreter ABI Platform Actions
astoncli-0.1.1-py3-none-any.whl Python 3 none any Details for astoncli-0.1.1-py3-none-any.whl

Total release size: 113.1 kB

Release files / astoncli-0.1.1.tar.gz

Download URL astoncli-0.1.1.tar.gz
Size 58.5 kB
Tags Source
SHA-256 checksum
How to use checksums
7fb624fdd8fcd6bcb3ee493c16a34878a5acf92867b6eac0a865b589421033a2
BLAKE2b-256 checksum
How to use checksums
128858243b6a84e6a0787c6c7f3b55a91ea16012f5b08206c6cd2c8942addb70
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.14.8

Release files / astoncli-0.1.1-py3-none-any.whl

Download URL astoncli-0.1.1-py3-none-any.whl
Size 54.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
0c57efe7c740a6e090cf4c15348a17d974a10abdfe09563ff750cdd483a4182b
BLAKE2b-256 checksum
How to use checksums
c1d5d050cff6645e9b4ed7db8e62f1ce04d2470582c51c70765983b7d36a0977
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.14.8

Security for astoncli 0.1.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page