nanoPyCodeAgent 0.1.0__tar.gz

nanopycodeagent-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,81 @@
+name: Release
+
+# Build, publish to PyPI, and create a GitHub Release when a v* tag is pushed.
+#
+# Concerns are split into three jobs, each with the minimum permissions it
+# needs, so the powerful id-token (PyPI) and contents:write (repo) scopes never
+# coexist in one job:
+#   build            -> no special permissions
+#   publish-to-pypi  -> id-token: write  (Trusted Publishing / OIDC, no tokens)
+#   github-release   -> contents: write  (create the release + upload assets)
+#
+# One-time prerequisite on PyPI — add a "pending publisher" at
+# https://pypi.org/manage/account/publishing/ matching:
+#   owner = minixalpha, repo = nanoPyCodeAgent,
+#   workflow = release.yml, environment = (leave blank; this workflow sets none).
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  build:
+    name: Build distributions
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 0 # full history + tags so hatch-vcs can derive the version
+      - name: Install uv
+        uses: astral-sh/setup-uv@08807647e7069bb48b6ef5acd8ec9567f424441b # v8.1.0
+      - name: Build
+        run: uv build
+      - name: Check distribution metadata
+        run: uvx twine check dist/*
+      - name: Upload artifacts
+        uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  publish-to-pypi:
+    name: Publish to PyPI
+    needs: build
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write # required for Trusted Publishing (OIDC)
+    steps:
+      - name: Download artifacts
+        uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - name: Install uv
+        uses: astral-sh/setup-uv@08807647e7069bb48b6ef5acd8ec9567f424441b # v8.1.0
+      - name: Publish to PyPI
+        # --check-url makes re-runs idempotent: files already on the index are
+        # skipped instead of failing the job on "file already exists".
+        run: uv publish --check-url https://pypi.org/simple/
+
+  github-release:
+    name: Create GitHub Release
+    needs: publish-to-pypi # only after a successful PyPI publish
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write # required to create the release and upload assets
+    steps:
+      - name: Download artifacts
+        uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ github.token }}
+          GH_REPO: ${{ github.repository }}
+        # --generate-notes builds notes from merged PRs since the previous tag;
+        # dist/* attaches the wheel and sdist as assets. Idempotent: skip if a
+        # release for this tag already exists, so re-runs don't fail.
+        run: |
+          gh release view "$GITHUB_REF_NAME" >/dev/null 2>&1 \
+            || gh release create "$GITHUB_REF_NAME" dist/* --generate-notes

nanopycodeagent-0.1.0/.gitignore

@@ -0,0 +1,218 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml

nanopycodeagent-0.1.0/.python-version

@@ -0,0 +1 @@
+3.13

nanopycodeagent-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 minixalpha
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

nanopycodeagent-0.1.0/PKG-INFO

@@ -0,0 +1,69 @@
+Metadata-Version: 2.4
+Name: nanoPyCodeAgent
+Version: 0.1.0
+Summary: A nano code agent built from scratch in pure Python.
+Project-URL: Homepage, https://github.com/minixalpha/nanoPyCodeAgent
+Project-URL: Repository, https://github.com/minixalpha/nanoPyCodeAgent
+Project-URL: Issues, https://github.com/minixalpha/nanoPyCodeAgent/issues
+Author: minixalpha
+License-Expression: MIT
+License-File: LICENSE
+Keywords: agent,ai,code-agent,llm
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.13
+Requires-Python: >=3.13
+Description-Content-Type: text/markdown
+
+# nanoPyCodeAgent
+
+[English](README.md) | [简体中文](README.zh-CN.md)
+
+A nano code agent built in pure Python.
+
+> "What I cannot create, I do not understand." — Richard Feynman, 1988
+
+## Usage
+
+nanoPyCodeAgent requires Python 3.13 or newer.
+
+### How to Run
+
+There are a few ways to run it — pick whichever fits your workflow.
+
+#### Run without installing
+
+Use `uvx` to run the latest release without installing anything:
+
+```bash
+uvx nanoPyCodeAgent
+```
+
+#### Run after installing
+
+Install it as a persistent command-line tool, then run it from anywhere:
+
+```bash
+uv tool install nanoPyCodeAgent   # or: pipx install nanoPyCodeAgent
+nanoPyCodeAgent
+```
+
+#### Run a branch or tagged version
+
+Run an unreleased branch or a specific release tag straight from GitHub:
+
+```bash
+# latest commit on a branch
+uvx --from "git+https://github.com/minixalpha/nanoPyCodeAgent@main" nanoPyCodeAgent
+
+# a specific tag
+uvx --from "git+https://github.com/minixalpha/nanoPyCodeAgent@v0.1.0" nanoPyCodeAgent
+```
+
+### How to Update
+
+Upgrade an installed tool to the latest release:
+
+```bash
+uv tool upgrade nanoPyCodeAgent   # or: pipx upgrade nanoPyCodeAgent
+```

nanopycodeagent-0.1.0/README.md

@@ -0,0 +1,52 @@
+# nanoPyCodeAgent
+
+[English](README.md) | [简体中文](README.zh-CN.md)
+
+A nano code agent built in pure Python.
+
+> "What I cannot create, I do not understand." — Richard Feynman, 1988
+
+## Usage
+
+nanoPyCodeAgent requires Python 3.13 or newer.
+
+### How to Run
+
+There are a few ways to run it — pick whichever fits your workflow.
+
+#### Run without installing
+
+Use `uvx` to run the latest release without installing anything:
+
+```bash
+uvx nanoPyCodeAgent
+```
+
+#### Run after installing
+
+Install it as a persistent command-line tool, then run it from anywhere:
+
+```bash
+uv tool install nanoPyCodeAgent   # or: pipx install nanoPyCodeAgent
+nanoPyCodeAgent
+```
+
+#### Run a branch or tagged version
+
+Run an unreleased branch or a specific release tag straight from GitHub:
+
+```bash
+# latest commit on a branch
+uvx --from "git+https://github.com/minixalpha/nanoPyCodeAgent@main" nanoPyCodeAgent
+
+# a specific tag
+uvx --from "git+https://github.com/minixalpha/nanoPyCodeAgent@v0.1.0" nanoPyCodeAgent
+```
+
+### How to Update
+
+Upgrade an installed tool to the latest release:
+
+```bash
+uv tool upgrade nanoPyCodeAgent   # or: pipx upgrade nanoPyCodeAgent
+```

nanopycodeagent-0.1.0/README.zh-CN.md

@@ -0,0 +1,52 @@
+# nanoPyCodeAgent
+
+[English](README.md) | [简体中文](README.zh-CN.md)
+
+一个用纯 Python 构建的 Nano 级别的代码智能体。
+
+> “凡我不能创造的,我便未能真正理解。” —— 理查德·费曼,1988
+
+## 使用
+
+nanoPyCodeAgent 需要 Python 3.13 或更高版本。
+
+### 如何运行
+
+有几种运行方式,任选其一即可。
+
+#### 免安装运行
+
+用 `uvx` 直接运行最新发布版,无需安装任何东西:
+
+```bash
+uvx nanoPyCodeAgent
+```
+
+#### 安装后运行
+
+将它作为常驻命令行工具安装,之后可在任意位置运行:
+
+```bash
+uv tool install nanoPyCodeAgent   # 或: pipx install nanoPyCodeAgent
+nanoPyCodeAgent
+```
+
+#### 运行某个分支或标签版本
+
+直接从 GitHub 运行未发布的分支,或某个具体的发布标签:
+
+```bash
+# 分支上的最新提交
+uvx --from "git+https://github.com/minixalpha/nanoPyCodeAgent@main" nanoPyCodeAgent
+
+# 某个具体 tag
+uvx --from "git+https://github.com/minixalpha/nanoPyCodeAgent@v0.1.0" nanoPyCodeAgent
+```
+
+### 如何更新
+
+将已安装的工具升级到最新发布版:
+
+```bash
+uv tool upgrade nanoPyCodeAgent   # 或: pipx upgrade nanoPyCodeAgent
+```

nanopycodeagent-0.1.0/docs/changelogs/0.1.x.md

@@ -0,0 +1,25 @@
+# Changelog — 0.1.x
+
+All notable changes in the **0.1.x** release series are documented here.
+
+## [Unreleased]
+
+## [0.1.0] - 2026-06-20
+
+### Added
+- uv-managed project with the console-script entry point `nanoPyCodeAgent`.
+- Tag-driven release pipeline: PyPI Trusted Publishing + GitHub Release.
+- Bilingual README (English / 简体中文).
+- changelogs and dev notes
+
+<!--
+When cutting a release, copy the relevant items from [Unreleased] into a new
+version section above it, e.g.:
+
+## [0.1.1] - YYYY-MM-DD
+
+### Added
+### Changed
+### Fixed
+### Removed
+-->

nanopycodeagent-0.1.0/docs/changelogs/README.md

@@ -0,0 +1,7 @@
+# Changelogs
+
+Changelogs for nanoPyCodeAgent, organized one file per `X.Y.x` release series
+(e.g. [`0.1.x.md`](0.1.x.md)).
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/).

nanopycodeagent-0.1.0/docs/dev_notes/README.md

@@ -0,0 +1,13 @@
+# Development Notes
+
+Development notes for nanoPyCodeAgent, organized one file per `X.Y.x` release
+series (e.g. `0.1.x.md`).
+
+Notes are bilingual, split by language:
+
+- [`zh-CN/`](zh-CN/) — **hand-written Chinese source** (source of truth)
+- [`en/`](en/) — **English, generated from the Chinese source** (do not edit by hand)
+
+These are free-form notes — insights, takeaways, and design decisions gathered
+while developing each series, with no fixed structure. User-facing changes live
+in [`../changelogs/`](../changelogs/).

nanopycodeagent-0.1.0/docs/dev_notes/en/0.1.x.md

@@ -0,0 +1,21 @@
+# Development Notes — 0.1.x
+
+> Generated from the Chinese source [`../zh-CN/0.1.x.md`](../zh-CN/0.1.x.md). Do not edit by hand.
+
+## 0.1.0 - 2026.06.20
+
+The main purpose of this project is to deepen my understanding of agents by building a code agent myself. Without writing one by hand at least once, I feel I can't really grasp the details. Agents are devouring the world at a visible pace, and I can't stay indifferent to that.
+
+I chose Python simply because I'm familiar with it, so that language-specific friction wouldn't get in the way of expressing what I mean while building by hand. Later I may build versions in other programming languages to further appreciate the differences between languages when building an agent.
+
+This release mainly sets up the project skeleton. My biggest takeaway is that building a project in public feels mentally very different from a private one. A private, for-myself project often carries a "vibe" mindset — sometimes you don't care much about the details, and as long as it works, it's fine. But building in public is a kind of public commitment: you have to be very careful about what you ship, and must not put out garbage that pollutes the world.
+
+I do use a code agent to generate things, but I follow a few principles.
+
+First, I deliberate over what it generates, again and again.
+
+Understand what the agent is doing, and keep questioning whether what it produced makes sense. I've found this process genuinely teaches me a lot. Knowledge-wise, I quickly pick up things I didn't know before — how to design a reasonable project structure, how to publish to PyPI, how to build a GitHub workflow — without having to search and filter on my own; I can learn the key parts directly. Beyond that, questioning what the AI generates leads me to learn things I didn't even know existed. For example, when I noticed `build-backend = "hatchling.build"` in `pyproject.toml` and wondered what it was and why it differed from the `build-backend = "uv_build"` in uv's official docs, the agent walked me through a detailed comparison, and from it I learned about dynamic versioning — and put what I'd just learned to use in the project. Later, reviewing the code, I noticed `pyproject.toml` no longer had a fixed version number, which left me a bit uneasy: I worried I wouldn't be able to quickly tell the project's version afterward. Through the discussion with the agent I learned the version can be obtained via `git describe`, and in the end decided to keep the dynamic-versioning design. All of this was learned in the course of "understanding what the AI actually generated"; had I only been vibing, I probably would never have learned any of it.
+
+Working with a code agent also gives me a better sense of its limitations — limitations I uncovered by questioning what the AI generated and repeatedly asking whether it was really best practice. Time and again I've noticed a particular flaw in the agent, a kind of "A + B < A and A + B < B" problem: you have the AI generate A and B, each fine on its own, but together they are problematic. For instance, I initially created the project with `uv init`, then — because I wanted to run it directly with uvx — switched it to the [Packaged applications](https://docs.astral.sh/uv/concepts/projects/init/#packaged-applications) layout, and what came out was a hybrid of the two. Only when I questioned why there was duplicated code, and whether that was best practice, did the agent change it to a cleaner version. Another example: when first building [release.yml](../../../.github/workflows/release.yml), the agent merged publishing to PyPI and creating the GitHub release into a single job "for simplicity" — but I didn't want that simplification; I only wanted to know the best practice, and in the end the agent split the two distinct concerns apart.
+
+Second, for the crucial parts, I still want to write them by hand as much as possible. This isn't one of those deadline-driven company projects; I don't need "delivery efficiency" — I need to taste as much as I can along the way. From past experience, people learn more from their mistakes, and I need to understand, through making errors, debugging, and revising, why a thing is designed the way it is and why it is written the way it is. Only for the relatively mechanical tasks do I let the agent generate things.

nanopycodeagent-0.1.0/docs/dev_notes/zh-CN/0.1.x.md

@@ -0,0 +1,21 @@
+# 开发笔记 — 0.1.x
+
+> 本文件为**手写中文源文件**(source of truth);英文版 [`../en/0.1.x.md`](../en/0.1.x.md) 由其生成。
+
+## 0.1.0 - 2026.06.20
+
+这个项目的主要目的，是我要通过对 Code Agent 的构建，增强对 Agent 的理解，如果不亲手写一次，我觉得自己难以理解其中的细节，agent 在以肉眼可见的速度吞噬世界，我不能对此无动于衷。
+
+选择 Python，单纯是因为我对 Python 熟悉，使得手工构建时，语言相关的内容不会阻挡我的表达，以后可能会通过构建其他编程语言的版本，来进一步体会不同语言构建 agent 时候的区别。
+
+这个版本主要完成了项目骨架的搭建，最主要的体会是一个公开构建的项目，和自己的私有项目，在心态上有很大不同。私有的，自用的项目，通常有种 "vibe" 心态，有时候并不在意一些细节，功能正常就 ok，但公开构建的项目，代表了自己的一种公开承诺，你需要对交付出去的东西慎之又慎，不能交付出去一个垃圾去污染这个世界。
+
+我会使用 Code Agent 去生成一些东西，但会有几点原则。
+
+一是对它生成的东西反复考量。
+
+弄清楚 Agent 在做什么，反复思考生成的东西的合理性。我发现这个过程真的让我学到很多，从知识上，会快速学到一些之前不知道的事，比如怎么设计合理的项目结构，怎么发布到 pypi，怎么构建 GitHub Workflow，我不再需要自己去搜索，筛选，而能直接学习关键环节。另外，通过质疑 AI 生成的东西，还能学到以前不知道的东西，比如我发现 `pyproject.toml` 里，`build-backend = "hatchling.build"` 是什么，为什么与 uv 官方文档里的 `build-backend = "uv_build"` 不一样时，Agent 详细对比了二者的不同，从中我了解到了动态版本号的知识，并且把新学到的东西用在了项目里，后来 review 代码，我又看到 `pyproject.toml` 里没有了固定版本号，让我又有点纠结，担心后续无法快速获取项目版本号，在与 agent 的讨论中，又学到了可以用 `git describe` 得到版本号，最终再决定保留动态版本号的设计。这些学到的东西，都是在“了解 AI 到底生成了什么”中学到的，如果只是 "vibe"，我大概永远学不到这些东西。
+
+从人与 Code Agent 的协作上，也更能了解 Agent 的局限性，而这些局限性，是在我质疑 AI 生成的东西，反复访问这是否是最佳实践中得到的。我多次发现 Agent 有种缺陷，即一种 "A + B < A 且 A + B < B" 的缺陷，你通过 AI 生成了 A 和 B，单纯看没问题，但合在一起有问题，比如我一开始是通过 "uv init" 生成的项目，后来因为想用 uvx 直接运行，又改成了 [Packaged applications](https://docs.astral.sh/uv/concepts/projects/init/#packaged-applications) 的结构，结果最终生成的是两种东西的混合体，在我质疑为什么代码有重复，这是否是最佳实践时，Agent 才改成了更干净的版本。又比如在最初构建 [release.yml](../../../.github/workflows/release.yml) 时，Agent 说为了简化把发布到 pypi 和 github release 合并在一个 job 中，但我并不想要这种简化，只想知道什么是最佳实践，最终 Agent 把两个不同的事做了拆分。
+
+二是关键的部分，我希望还是能尽量手写。这并非公司里那些有 deadline 的项目，我不需要“交付效率”，而需要在这个过程尝到尽可能多的东西。从过去的经验看，人在错误中能学到更多的东西，我需要在出错，调试，修改中，了解一个东西为什么要这样设计，为什么要这样写。只有那些相对比较机械的任务，我会通过 Agent 来生成。

nanopycodeagent-0.1.0/pyproject.toml

@@ -0,0 +1,34 @@
+[project]
+name = "nanoPyCodeAgent"
+dynamic = ["version"]
+description = "A nano code agent built from scratch in pure Python."
+readme = "README.md"
+requires-python = ">=3.13"
+license = "MIT"
+license-files = ["LICENSE"]
+authors = [{ name = "minixalpha" }]
+keywords = ["agent", "llm", "code-agent", "ai"]
+classifiers = [
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3.13",
+    "Intended Audience :: Developers",
+]
+dependencies = []
+
+[project.urls]
+Homepage = "https://github.com/minixalpha/nanoPyCodeAgent"
+Repository = "https://github.com/minixalpha/nanoPyCodeAgent"
+Issues = "https://github.com/minixalpha/nanoPyCodeAgent/issues"
+
+[project.scripts]
+nanoPyCodeAgent = "nanopycodeagent:main"
+
+[build-system]
+requires = ["hatchling", "hatch-vcs"]
+build-backend = "hatchling.build"
+
+[tool.hatch.version]
+source = "vcs"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/nanopycodeagent"]

nanopycodeagent-0.1.0/src/nanopycodeagent/__init__.py

@@ -0,0 +1,2 @@
+def main() -> None:
+    print("hello nanoPyCodeAgent")

nanopycodeagent-0.1.0/uv.lock

@@ -0,0 +1,7 @@
+version = 1
+revision = 3
+requires-python = ">=3.13"
+
+[[package]]
+name = "nanopycodeagent"
+source = { editable = "." }