rimpack 0.1.0__tar.gz

rimpack-0.1.0/.github/workflows/docs.yml

@@ -0,0 +1,48 @@
+name: docs
+
+on:
+  push:
+    branches:
+      - main
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: pages
+  cancel-in-progress: true
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v4
+
+      - name: Configure GitHub Pages
+        uses: actions/configure-pages@v5
+
+      - name: Build docs site
+        uses: actions/jekyll-build-pages@v1
+        with:
+          source: docs
+          destination: ./_site
+
+      - name: Upload Pages artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: ./_site
+
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

rimpack-0.1.0/.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/
+.pytest-tmp/
+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/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# Repository-local test scratch files
+tests/__tmp_*.xml

rimpack-0.1.0/.python-version

@@ -0,0 +1 @@
+3.12

rimpack-0.1.0/AGENTS.md

@@ -0,0 +1,287 @@
+# AGENTS.md
+
+## Purpose
+
+This repository contains a Python-based RimWorld modpack tool.
+
+Agents working in this repository must treat the project as a spec-driven implementation. Code, tests, and documentation should follow the spec files in `specs/`.
+
+Primary tooling assumptions:
+
+- Python
+- strict `basedpyright`
+- `ruff`
+- `pytest`
+
+---
+
+## Core working rules
+
+1. Read the relevant spec files before changing code.
+2. Treat the spec files in `specs/` as authoritative unless the task explicitly changes the spec.
+3. Keep changes small, local, and easy to review.
+4. Prefer explicit, simple designs over clever or implicit ones.
+5. Do not introduce format or schema changes silently.
+6. When behavior changes, update tests and docs in the same change.
+7. Preserve determinism and diff-friendliness in generated outputs.
+
+---
+
+## Authoritative spec files
+
+Agents should treat these files as the primary source of truth for data formats and behavior:
+
+- `specs/modpack_folder_layout_spec.md`
+- `specs/rimworld_modpack_list_format_spec.md`
+- `specs/pack_toml_spec.md`
+- `specs/ordering_toml_spec.md`
+- `specs/activation_toml_spec.md`
+
+If `specs/README.md` exists, read it first for reading order and relationships between specs.
+
+---
+
+## Repository expectations
+
+This project should be implemented as a Python codebase with:
+
+- strong static typing
+- strict `basedpyright` compliance
+- `ruff` compliance
+- `pytest` test coverage
+
+Agents should write code that is:
+
+- typed
+- modular
+- readable
+- deterministic
+- easy to test
+
+Avoid magical behavior, hidden global state, and unnecessary abstraction.
+
+---
+
+## Python standards
+
+### Typing
+- All new Python code should include explicit type annotations.
+- Code must pass strict `basedpyright`.
+- Prefer precise types over `Any`.
+- Avoid untyped dictionaries for structured data when a `dataclass`, `TypedDict`, or protocol is more appropriate.
+- Keep public function signatures stable and explicit.
+
+### Style
+- Follow `ruff` rules configured by the repository.
+- Prefer clear, boring code over compact cleverness.
+- Keep functions focused.
+- Prefer `pathlib.Path` over raw path strings in Python code where practical.
+- Prefer `dataclasses` for structured internal models unless a different choice is clearly justified.
+
+### Testing
+- All behavior changes should include or update tests.
+- Use `pytest`.
+- Favor small, targeted unit tests.
+- Add regression tests for parser, resolver, activation, and ordering behavior when relevant.
+- Keep tests deterministic.
+- When tests exercise config loading or install-path discovery, isolate them from machine-local state by overriding the config path and clearing or setting relevant environment variables explicitly.
+- Whenever changing Python source files, run both `ruff` and `basedpyright` before finishing the task.
+
+---
+
+## Implementation priorities
+
+When implementing features, preserve these priorities:
+
+1. Correctness against spec
+2. Deterministic output
+3. Preservation of user-authored text where required
+4. Readability and maintainability
+5. Performance only after correctness and clarity
+
+Do not trade away spec correctness for speculative optimization.
+
+---
+
+## Format-specific guidance
+
+### `.list` files
+- Treat `.list` files as text-first authored documents.
+- Preserve untouched lines exactly.
+- Preserve comments and blank lines.
+- Preserve unknown lines unchanged.
+- Do not rewrite whole files just to normalize formatting.
+- Apply the smallest practical edit for UI-driven changes.
+- Parsers and editors for `.list` files should retain enough source structure to support comment- and formatting-preserving edits later, including raw line text and original line endings.
+
+### `pack.toml`
+- Treat `pack.toml` as a small root manifest.
+- Do not store full mod lists in it.
+- Do not store generated lock data, diagnostics payloads, caches, or UI state in it.
+- Preserve comments and unrelated fields when editing if the TOML library supports it.
+- Prefer preservation-friendly parsing/editing models over lossy deserialize-then-reserialize approaches, because future programmatic edits must keep comments, section layout, and formatting stable where possible.
+
+### ordering and activation rules
+- Keep ordering rules separate from activation rules.
+- Ordering rules constrain relative order.
+- Activation rules control whether candidate entries are active.
+- Do not merge these concepts into one file or one resolver stage unless the spec is explicitly changed.
+- The central load-order implementation lives in `rimpack.core.modpack.modpack.generate_modpack_load_order`; update that function whenever ordering behavior changes, including authored ordering rules or `About.xml`-derived ordering metadata.
+
+---
+
+## Change management rules
+
+### If code changes require a spec change
+Update the relevant file in `specs/` in the same change.
+
+### If a spec is ambiguous
+Do not invent a large interpretation silently.
+Prefer the smallest reasonable implementation that matches the current wording.
+If necessary, leave a clear note in code comments or task notes about the ambiguity.
+
+### If a requested change conflicts with the existing spec
+Update the spec first or as part of the same change. Do not leave code and spec drifting apart.
+
+---
+
+## File organization guidance
+
+Agents should respect the intended separation between:
+
+- authored project files
+- generated files
+- rules
+- lock data
+- tests
+- implementation code
+
+Do not mix generated artifacts into authored source directories.
+
+Do not place agent scratch files, temporary exports, or local caches into the repository unless explicitly asked.
+
+### Namespace boundaries
+- `rimpack.core.mods` is reserved for parsing RimWorld mod files and folders such as `About.xml`, `LoadFolders.xml`, and on-disk mod directories.
+- Modpack-authored project formats such as `.list`, `pack.toml`, and rule files should live outside `rimpack.core.mods`.
+- Do not place modpack project parsers into the RimWorld mod metadata namespace.
+- Whenever modpack parsing or editing code changes for `.list`, `pack.toml`, or rule files, also check whether `rimpack init` still creates the right authored structure and update it in the same change if needed.
+
+---
+
+## Testing expectations by area
+
+### Parser changes
+Add tests for:
+- valid entries
+- disabled entries
+- comments
+- blank lines
+- unknown lines
+- preservation-sensitive behavior
+
+When changing code that parses RimWorld mod files or folders, also check for a local Steam RimWorld installation or workshop library and, if available, test the change against real mods in addition to unit tests. Prefer using the repository CLI command `rimpack load-mods` for this real-life parser verification.
+
+### Manifest changes
+Add tests for:
+- required fields
+- path handling
+- ordering of `mod_files`
+- ordering of rule file arrays
+- invalid manifest shapes
+
+### Ordering changes
+Add tests for:
+- stable ordering
+- before/after constraints
+- missing references
+- cycle diagnostics
+
+### Activation changes
+Add tests for:
+- `when_all_present`
+- `when_all_absent`
+- `when_any_present`
+- `when_any_absent`
+- inactive-by-rule behavior
+- duplicate rules for the same mod if applicable
+
+### Lock-file changes
+Add tests for:
+- deterministic output
+- resolved entries
+- unresolved entries
+- disabled entries
+- final load order contents
+
+---
+
+## Preferred implementation style
+
+Prefer code that is easy for another agent or human to continue.
+
+Good traits:
+
+- small modules
+- explicit models
+- pure functions where practical
+- thin I/O boundaries
+- minimal hidden coupling
+- resolve external context once at the boundary, then pass it into helpers explicitly instead of having deep helpers rediscover config, environment, or filesystem state
+
+Avoid:
+
+- giant all-in-one classes
+- vague helper utilities with mixed responsibilities
+- schema logic duplicated across multiple modules
+- silent fallback behavior that hides invalid states
+- helpers that reach back into config or environment discovery when the needed value can be passed as an argument
+
+---
+
+## When editing generated-output logic
+
+Generated files should be:
+
+- reproducible
+- stable in ordering
+- low-noise in diffs
+- straightforward to inspect
+
+Avoid timestamps or nondeterministic identifiers unless explicitly required by spec.
+
+---
+
+## Documentation expectations
+
+When introducing a new persistent format, schema field, rule type, or pipeline stage:
+
+1. update the relevant spec in `specs/`
+2. update tests
+3. update any code-level docs or README references if needed
+
+Do not let implementation-only knowledge become the source of truth for a persisted format.
+
+---
+
+## Command assumptions
+
+Use repository-configured commands for:
+
+- linting with `ruff`
+- type checking with `basedpyright`
+- tests with `pytest`
+
+If command names are defined in project files such as `pyproject.toml`, follow those definitions rather than inventing new ones.
+
+---
+
+## Summary for agents
+
+When in doubt:
+
+- read the relevant spec first
+- keep code explicit
+- preserve authored text carefully
+- keep generated output deterministic
+- update tests with behavior changes
+- keep code, tests, and specs aligned

rimpack-0.1.0/PKG-INFO

@@ -0,0 +1,119 @@
+Metadata-Version: 2.4
+Name: rimpack
+Version: 0.1.0
+Summary: Add your description here
+Requires-Python: >=3.12
+Requires-Dist: platformdirs>=4.4.0
+Requires-Dist: pydantic>=2.12.0
+Requires-Dist: rich>=14.3.3
+Requires-Dist: steamworkspy>=0.0.2
+Requires-Dist: typer>=0.19.2
+Description-Content-Type: text/markdown
+
+# rimpack
+
+`rimpack` is a Python CLI for building, validating, and launching RimWorld modpacks from
+human-authored project files.
+
+It treats a modpack as a normal project directory:
+
+- `pack.toml` is the root manifest.
+- `mods/*.list` files define authored mod intent.
+- `rules/` contains optional activation and ordering rules.
+- `generated/` contains outputs that can be regenerated.
+- launch state stays machine-local instead of mutating the real RimWorld install.
+
+The repository is spec-driven. The authoritative behavior and file-format definitions live in
+[`specs/`](./specs).
+
+## Current Capabilities
+
+Today, `rimpack` can:
+
+- initialize a new modpack project with `rimpack init`
+- inspect RimWorld mods with `rimpack load-mods`
+- resolve Steam Workshop items with `rimpack resolve steam`
+- subscribe and unsubscribe Workshop mods
+- add mod references to a declared `.list` file with `rimpack add`
+- append ordering rules with `rimpack add-ordering-rule`
+- validate a modpack before launch with `rimpack validate`
+- launch a modpack through a symlinked runtime tree with `rimpack launch`
+
+Activation rule files are supported by the project format and validation pipeline, but there is
+not yet a dedicated CLI command to author them.
+
+## Install
+
+The project uses Python 3.12+ and `uv`.
+
+```powershell
+uv sync --dev
+uv run rimpack --help
+```
+
+You can also run the console script directly after syncing:
+
+```powershell
+rimpack --help
+```
+
+## First Run
+
+Running `rimpack` with no command creates a user-local config file if one does not already exist.
+That config stores absolute machine-local paths such as:
+
+- the RimWorld install directory
+- the Steam Workshop content directory for app `294100`
+
+You can also provide them through environment variables:
+
+- `RIMWORLD_FOLDER`
+- `STEAM_WORKSHOP_FOLDER`
+
+## Quick Start
+
+Initialize a new pack:
+
+```powershell
+uv run rimpack init .\MyPack
+```
+
+Add a Workshop mod to the `@libraries` list:
+
+```powershell
+uv run rimpack add @libraries steam:2009463077
+```
+
+Validate the pack:
+
+```powershell
+uv run rimpack validate
+```
+
+Launch it:
+
+```powershell
+uv run rimpack launch
+```
+
+## Documentation
+
+Browsable project documentation lives in [`docs/`](./docs):
+
+- [`docs/index.md`](./docs/index.md)
+- [`docs/getting-started.md`](./docs/getting-started.md)
+- [`docs/cli.md`](./docs/cli.md)
+- [`docs/modpack-format.md`](./docs/modpack-format.md)
+- [`docs/configuration.md`](./docs/configuration.md)
+
+A GitHub Actions workflow publishes those docs to GitHub Pages on pushes to `main`.
+
+## Development
+
+The expected local checks are:
+
+```powershell
+uv run ruff check .
+uv run basedpyright
+uv run pytest
+```