lucky-cli 0.0.3__tar.gz

lucky_cli-0.0.3/.github/workflows/release.yml

@@ -0,0 +1,34 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - run: pip install build twine pytest setuptools-scm
+
+      - run: pip install -e .
+
+      - run: pytest
+
+      - run: python -m build
+
+      - run: twine check dist/*
+
+      - name: Publish to PyPI
+        env:
+          TWINE_USERNAME: __token__
+          TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }}
+        run: twine upload dist/*

lucky_cli-0.0.3/.gitignore

@@ -0,0 +1,220 @@
+# 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
+.worktrees/
+/sdd/

lucky_cli-0.0.3/.python-version

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

lucky_cli-0.0.3/AGENTS.md

@@ -0,0 +1,150 @@
+# CLAUDE.md
+
+Guidance for Claude Code when working in this repository.
+
+## Project
+
+`lucky-cli` is a production-grade Python CLI package (lottery ticket generator/checker/stats), installed as the `lucky` command. This is a real PyPI-ready project, not a toy script — code should be held to the same bar as tools like `git`, `docker`, or `poetry`: clean architecture, no half-finished features, no dead code.
+
+The repo is currently a bare skeleton (`pyproject.toml`, `main.py`, `LICENSE`, `README.md`) — most of the structure below does not exist yet and needs to be built.
+
+## Tech stack (strict — do not substitute)
+
+- Python 3.11+
+- Typer for the CLI (not Click directly, even though Typer wraps it)
+- Rich for all terminal UI (tables, panels, progress bars, spinners) — avoid raw `print()` except for debugging
+- SQLite for local persistence
+- SQLAlchemy as the ORM layer
+- httpx as the HTTP client
+- pytest for tests
+- setuptools + setuptools-scm for versioning (version comes from git tags, never hardcoded)
+- GitHub Actions for CI/CD
+- dev workflow uses `uv` locally (`uv run`, `uv sync`, etc.)
+
+## Project structure
+
+```
+lucky-cli/
+├── pyproject.toml
+├── README.md
+├── LICENSE
+├── CHANGELOG.md
+├── src/
+│   └── lucky/
+│       ├── __init__.py
+│       ├── cli.py
+│       ├── config.py
+│       ├── commands/
+│       │   ├── pick.py
+│       │   ├── check.py
+│       │   └── show.py
+│       ├── lottery/
+│       │   ├── base.py        # Game protocol/ABC + registry
+│       │   ├── powerball.py
+│       │   ├── mega.py
+│       │   └── generator.py
+│       ├── database/
+│       │   ├── db.py
+│       │   ├── models.py
+│       │   └── repository.py
+│       ├── updater/
+│       │   ├── updater.py
+│       │   ├── sources.py
+│       │   └── client.py
+│       └── console/
+│           └── rich.py
+└── tests/
+```
+
+## CLI surface
+
+Entry point: `lucky` (installed via `pip install lucky-cli`).
+
+| Command | Purpose |
+|---|---|
+| `lucky pick <game> [--count N]` | Generate N valid random tickets |
+| `lucky check <game> <n1..n5> --special <s>` | Compare a ticket against the latest draw, show match count |
+| `lucky show <game>` | Show the latest draw (date, numbers, special, jackpot) in a Rich panel — default view |
+| `lucky show <game> --history [--limit N]` | Last N draws in a Rich table |
+| `lucky show <game> --stats` | Number/special frequency, hot/cold numbers, odd/even distribution |
+| `lucky --version` | Version read dynamically via `importlib.metadata.version`, never hardcoded |
+
+Only three top-level commands: `pick`, `check`, `show`. `show` defaults to the latest draw; `--history` and `--stats` switch its view (mutually exclusive — don't combine them).
+
+Supported games:
+- Powerball: 5 numbers (1–69) + 1 special (1–26)
+- Mega Millions: 5 numbers (1–70) + 1 special (1–25)
+
+### Game extensibility (design requirement)
+
+Only Powerball and Mega Millions exist today, but the game layer must stay open for new games without touching `commands/`, `database/`, or `updater/` code:
+
+- `lottery/base.py` defines a `Game` abstraction (ABC or `Protocol`) with the rules every game must expose: name/slug, number range, count of main numbers, special-number range (or none), and a validator for a ticket.
+- Each game (`powerball.py`, `mega.py`, future ones) is a small data-driven implementation of `Game` — no game-specific branching (`if game == "powerball"`) anywhere outside `lottery/`.
+- `lottery/__init__.py` (or `base.py`) exposes a registry (dict or simple lookup function) mapping a game slug string to its `Game` instance, so `commands/pick.py`, `check.py`, `show.py` resolve the game generically by slug and call shared logic (`generator.py`, stats, checker) against the `Game` interface.
+- Adding a game should be: one new file in `lottery/`, one registry entry, zero changes to CLI command code or the `draws` table schema (it's already game-agnostic via `game` and the JSON number arrays — see Data layer).
+
+## Automatic update flow (every invocation)
+
+Every `lucky` invocation must, before running the user's command:
+1. Check local SQLite DB timestamp
+2. Hit the remote lottery data source (mock API is acceptable)
+3. If new draws exist: download, update SQLite, show a Rich progress bar
+4. If already up to date: stay silent — no spinner, no output
+5. If offline/network failure: fall back silently to the cached DB, never crash
+
+This auto-update behavior is a core requirement, not optional — don't let a feature command (`pick`, `check`, `show`) skip it.
+
+## Data layer
+
+SQLite DB path:
+- Linux/macOS: `~/.lucky-cli/lucky.db`
+- Windows: `%USERPROFILE%\.lucky-cli\lucky.db`
+
+`draws` table — one row per draw, numbers stored as JSON arrays so any game's main/special count fits without a migration:
+
+```sql
+draws (
+  id INTEGER PRIMARY KEY,
+  game TEXT NOT NULL,    -- slug, matches the lottery registry (e.g. "powerball")
+  date TEXT NOT NULL,
+  main TEXT NOT NULL,    -- JSON array, e.g. "[12,18,33,44,61]"
+  special TEXT NOT NULL, -- JSON array, e.g. "[9]" — "[]" if a game has none
+  jackpot TEXT,
+  UNIQUE(game, date)
+)
+```
+
+The SQLAlchemy model exposes `main`/`special` as typed list properties (`json.loads`/`json.dumps` under the hood), not raw strings. `stats` unpacks the arrays in Python for frequency counts rather than relying on SQL `GROUP BY`.
+
+## Versioning — agent-driven, fully automated
+
+Version numbers are never hand-edited in code. Before cutting a release:
+1. Read commit history since the last tag
+2. Classify: `feat:` → MINOR, `fix:` → PATCH, `feat!:`/`BREAKING CHANGE:` → MAJOR
+3. Compute the next semver deterministically from that classification
+4. Update `CHANGELOG.md` with a `## vX.Y.Z` section, grouped by `### Features` / `### Fixes`
+5. Create the tag with `git tag vX.Y.Z`
+
+Commit message convention (Conventional Commits, strictly enforced): `feat:`, `fix:`, `docs:`, `refactor:`, `test:`, `chore:`, with `feat!:` or a `BREAKING CHANGE:` footer for breaking changes.
+
+## CI/CD
+
+`.github/workflows/release.yml` triggers on `push: tags: ["v*"]` and must: run pytest, `python -m build`, `twine check dist/*`, then `twine upload dist/*` using a `PYPI_API_TOKEN` secret. Don't add steps that bypass tests before publish.
+
+## Testing
+
+pytest must cover: ticket generator correctness, stats calculations, checker logic, and database operations. Run with `uv run pytest`.
+
+## Local dev
+
+- `uv sync` to install deps
+- `uv run lucky --help` / `uv run pytest` to exercise the CLI/tests without a full install
+- `uv run lucky <command>` for manual testing of new commands
+
+## Conventions to hold the line on
+
+- No raw `print()` in command code — route all output through `src/lucky/console/rich.py` helpers
+- No bypassing the update-check flow in any command
+- No hardcoded version strings — always `importlib.metadata.version("lucky-cli")`
+- Network errors must degrade to cached-DB behavior, never raise to the user

lucky_cli-0.0.3/CLAUDE.md

@@ -0,0 +1,150 @@
+# CLAUDE.md
+
+Guidance for Claude Code when working in this repository.
+
+## Project
+
+`lucky-cli` is a production-grade Python CLI package (lottery ticket generator/checker/stats), installed as the `lucky` command. This is a real PyPI-ready project, not a toy script — code should be held to the same bar as tools like `git`, `docker`, or `poetry`: clean architecture, no half-finished features, no dead code.
+
+The repo is currently a bare skeleton (`pyproject.toml`, `main.py`, `LICENSE`, `README.md`) — most of the structure below does not exist yet and needs to be built.
+
+## Tech stack (strict — do not substitute)
+
+- Python 3.11+
+- Typer for the CLI (not Click directly, even though Typer wraps it)
+- Rich for all terminal UI (tables, panels, progress bars, spinners) — avoid raw `print()` except for debugging
+- SQLite for local persistence
+- SQLAlchemy as the ORM layer
+- httpx as the HTTP client
+- pytest for tests
+- setuptools + setuptools-scm for versioning (version comes from git tags, never hardcoded)
+- GitHub Actions for CI/CD
+- dev workflow uses `uv` locally (`uv run`, `uv sync`, etc.)
+
+## Project structure
+
+```
+lucky-cli/
+├── pyproject.toml
+├── README.md
+├── LICENSE
+├── CHANGELOG.md
+├── src/
+│   └── lucky/
+│       ├── __init__.py
+│       ├── cli.py
+│       ├── config.py
+│       ├── commands/
+│       │   ├── pick.py
+│       │   ├── check.py
+│       │   └── show.py
+│       ├── lottery/
+│       │   ├── base.py        # Game protocol/ABC + registry
+│       │   ├── powerball.py
+│       │   ├── mega.py
+│       │   └── generator.py
+│       ├── database/
+│       │   ├── db.py
+│       │   ├── models.py
+│       │   └── repository.py
+│       ├── updater/
+│       │   ├── updater.py
+│       │   ├── sources.py
+│       │   └── client.py
+│       └── console/
+│           └── rich.py
+└── tests/
+```
+
+## CLI surface
+
+Entry point: `lucky` (installed via `pip install lucky-cli`).
+
+| Command | Purpose |
+|---|---|
+| `lucky pick <game> [--count N]` | Generate N valid random tickets |
+| `lucky check <game> <n1..n5> --special <s>` | Compare a ticket against the latest draw, show match count |
+| `lucky show <game>` | Show the latest draw (date, numbers, special, jackpot) in a Rich panel — default view |
+| `lucky show <game> --history [--limit N]` | Last N draws in a Rich table |
+| `lucky show <game> --stats` | Number/special frequency, hot/cold numbers, odd/even distribution |
+| `lucky --version` | Version read dynamically via `importlib.metadata.version`, never hardcoded |
+
+Only three top-level commands: `pick`, `check`, `show`. `show` defaults to the latest draw; `--history` and `--stats` switch its view (mutually exclusive — don't combine them).
+
+Supported games:
+- Powerball: 5 numbers (1–69) + 1 special (1–26)
+- Mega Millions: 5 numbers (1–70) + 1 special (1–25)
+
+### Game extensibility (design requirement)
+
+Only Powerball and Mega Millions exist today, but the game layer must stay open for new games without touching `commands/`, `database/`, or `updater/` code:
+
+- `lottery/base.py` defines a `Game` abstraction (ABC or `Protocol`) with the rules every game must expose: name/slug, number range, count of main numbers, special-number range (or none), and a validator for a ticket.
+- Each game (`powerball.py`, `mega.py`, future ones) is a small data-driven implementation of `Game` — no game-specific branching (`if game == "powerball"`) anywhere outside `lottery/`.
+- `lottery/__init__.py` (or `base.py`) exposes a registry (dict or simple lookup function) mapping a game slug string to its `Game` instance, so `commands/pick.py`, `check.py`, `show.py` resolve the game generically by slug and call shared logic (`generator.py`, stats, checker) against the `Game` interface.
+- Adding a game should be: one new file in `lottery/`, one registry entry, zero changes to CLI command code or the `draws` table schema (it's already game-agnostic via `game` and the JSON number arrays — see Data layer).
+
+## Automatic update flow (every invocation)
+
+Every `lucky` invocation must, before running the user's command:
+1. Check local SQLite DB timestamp
+2. Hit the remote lottery data source (mock API is acceptable)
+3. If new draws exist: download, update SQLite, show a Rich progress bar
+4. If already up to date: stay silent — no spinner, no output
+5. If offline/network failure: fall back silently to the cached DB, never crash
+
+This auto-update behavior is a core requirement, not optional — don't let a feature command (`pick`, `check`, `show`) skip it.
+
+## Data layer
+
+SQLite DB path:
+- Linux/macOS: `~/.lucky-cli/lucky.db`
+- Windows: `%USERPROFILE%\.lucky-cli\lucky.db`
+
+`draws` table — one row per draw, numbers stored as JSON arrays so any game's main/special count fits without a migration:
+
+```sql
+draws (
+  id INTEGER PRIMARY KEY,
+  game TEXT NOT NULL,    -- slug, matches the lottery registry (e.g. "powerball")
+  date TEXT NOT NULL,
+  main TEXT NOT NULL,    -- JSON array, e.g. "[12,18,33,44,61]"
+  special TEXT NOT NULL, -- JSON array, e.g. "[9]" — "[]" if a game has none
+  jackpot TEXT,
+  UNIQUE(game, date)
+)
+```
+
+The SQLAlchemy model exposes `main`/`special` as typed list properties (`json.loads`/`json.dumps` under the hood), not raw strings. `stats` unpacks the arrays in Python for frequency counts rather than relying on SQL `GROUP BY`.
+
+## Versioning — agent-driven, fully automated
+
+Version numbers are never hand-edited in code. Before cutting a release:
+1. Read commit history since the last tag
+2. Classify: `feat:` → MINOR, `fix:` → PATCH, `feat!:`/`BREAKING CHANGE:` → MAJOR
+3. Compute the next semver deterministically from that classification
+4. Update `CHANGELOG.md` with a `## vX.Y.Z` section, grouped by `### Features` / `### Fixes`
+5. Create the tag with `git tag vX.Y.Z`
+
+Commit message convention (Conventional Commits, strictly enforced): `feat:`, `fix:`, `docs:`, `refactor:`, `test:`, `chore:`, with `feat!:` or a `BREAKING CHANGE:` footer for breaking changes.
+
+## CI/CD
+
+`.github/workflows/release.yml` triggers on `push: tags: ["v*"]` and must: run pytest, `python -m build`, `twine check dist/*`, then `twine upload dist/*` using a `PYPI_API_TOKEN` secret. Don't add steps that bypass tests before publish.
+
+## Testing
+
+pytest must cover: ticket generator correctness, stats calculations, checker logic, and database operations. Run with `uv run pytest`.
+
+## Local dev
+
+- `uv sync` to install deps
+- `uv run lucky --help` / `uv run pytest` to exercise the CLI/tests without a full install
+- `uv run lucky <command>` for manual testing of new commands
+
+## Conventions to hold the line on
+
+- No raw `print()` in command code — route all output through `src/lucky/console/rich.py` helpers
+- No bypassing the update-check flow in any command
+- No hardcoded version strings — always `importlib.metadata.version("lucky-cli")`
+- Network errors must degrade to cached-DB behavior, never raise to the user

lucky_cli-0.0.3/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 PyDeployer
+
+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.