pyrailworks 0.1.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,32 @@
1
+ name: CI
2
+
3
+ on:
4
+ push:
5
+ branches: [ "main" ]
6
+ pull_request:
7
+ branches: [ "main" ]
8
+
9
+ jobs:
10
+ test:
11
+ runs-on: ubuntu-latest
12
+ strategy:
13
+ fail-fast: false
14
+ matrix:
15
+ python-version: ["3.10", "3.11", "3.12", "3.13"]
16
+
17
+ steps:
18
+ - uses: actions/checkout@v4
19
+
20
+ - name: Set up Python ${{ matrix.python-version }}
21
+ uses: actions/setup-python@v5
22
+ with:
23
+ python-version: ${{ matrix.python-version }}
24
+
25
+ - name: Install dependencies
26
+ run: |
27
+ python -m pip install --upgrade pip
28
+ pip install .[dev]
29
+
30
+ - name: Run tests
31
+ run: |
32
+ pytest -v
@@ -0,0 +1,32 @@
1
+ name: Publish to PyPI
2
+
3
+ on:
4
+ release:
5
+ types: [published]
6
+ workflow_dispatch:
7
+
8
+ jobs:
9
+ pypi-publish:
10
+ name: Upload release to PyPI
11
+ runs-on: ubuntu-latest
12
+ permissions:
13
+ id-token: write
14
+ steps:
15
+ - uses: actions/checkout@v4
16
+
17
+ - name: Set up Python
18
+ uses: actions/setup-python@v5
19
+ with:
20
+ python-version: "3.12"
21
+
22
+ - name: Install build
23
+ run: |
24
+ python -m pip install --upgrade pip
25
+ pip install build
26
+
27
+ - name: Build distribution artifacts
28
+ run: |
29
+ python -m build
30
+
31
+ - name: Publish package distributions to PyPI
32
+ uses: pypa/gh-action-pypi-publish@release/v1
@@ -0,0 +1,10 @@
1
+ .venv/
2
+ __pycache__/
3
+ *.pyc
4
+ .pytest_cache/
5
+ .coverage
6
+ htmlcov/
7
+ dist/
8
+ build/
9
+ *.egg-info/
10
+ .scratch/
@@ -0,0 +1,15 @@
1
+ # pyrailworks
2
+
3
+ ## Agent skills
4
+
5
+ ### Issue tracker
6
+
7
+ Issues and specs live in GitHub Issues using the `gh` CLI. See `docs/agents/issue-tracker.md`.
8
+
9
+ ### Triage labels
10
+
11
+ Canonical triage roles (`needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`). See `docs/agents/triage-labels.md`.
12
+
13
+ ### Domain docs
14
+
15
+ Single-context repository layout (`CONTEXT.md` and `docs/adr/`). See `docs/agents/domain.md`.
@@ -0,0 +1,89 @@
1
+ Metadata-Version: 2.5
2
+ Name: pyrailworks
3
+ Version: 0.1.0
4
+ Summary: Python client library for the Public RO Railworks Irish Rail Engineering Works API
5
+ Author: Irishsmurf
6
+ License-Expression: MIT
7
+ Classifier: License :: OSI Approved :: MIT License
8
+ Classifier: Operating System :: OS Independent
9
+ Classifier: Programming Language :: Python :: 3
10
+ Classifier: Programming Language :: Python :: 3.10
11
+ Classifier: Programming Language :: Python :: 3.11
12
+ Classifier: Programming Language :: Python :: 3.12
13
+ Classifier: Typing :: Typed
14
+ Requires-Python: >=3.10
15
+ Requires-Dist: httpx>=0.24.0
16
+ Requires-Dist: pydantic>=2.0.0
17
+ Provides-Extra: dev
18
+ Requires-Dist: pytest-asyncio>=0.23.0; extra == 'dev'
19
+ Requires-Dist: pytest>=8.0.0; extra == 'dev'
20
+ Requires-Dist: respx>=0.21.0; extra == 'dev'
21
+ Description-Content-Type: text/markdown
22
+
23
+ # pyrailworks
24
+
25
+ Python client library for the Public RO Railworks API ([https://railworks.paddez.com/docs](https://railworks.paddez.com/docs)).
26
+
27
+ Provides queryable access to Iarnród Éireann's (Irish Rail) planned engineering works, station days, change logs, and iCalendar feeds.
28
+
29
+ ## Installation
30
+
31
+ ```bash
32
+ pip install pyrailworks
33
+ ```
34
+
35
+ ## Quick Start
36
+
37
+ ### Synchronous Client
38
+
39
+ ```python
40
+ from pyrailworks import RailworksClient, LineName
41
+
42
+ with RailworksClient() as client:
43
+ # 1. Health check
44
+ health = client.get_health()
45
+ print("Upstream checked at:", health.source.checked_at)
46
+
47
+ # 2. List stations
48
+ stations = client.list_stations()
49
+ print(f"Total stations: {len(stations)}")
50
+
51
+ # 3. Check affected days for a station
52
+ days_resp = client.get_station_days("WBROK")
53
+ for day in days_resp.days:
54
+ print(f"Station {days_resp.station.name} affected on {day.date}: {day.effect.value}")
55
+
56
+ # 4. List active notices on a line
57
+ notices = client.list_notices(line=LineName.DART, status="active")
58
+ for notice in notices.notices:
59
+ print(f"Notice {notice.id}: {notice.heading} ({notice.starts_on} to {notice.ends_on})")
60
+
61
+ # 5. Follow changes with automatic cursor traversal
62
+ for event in client.iter_changes():
63
+ print(f"Change event: {event.type.value} on notice {event.notice_id}")
64
+ ```
65
+
66
+ ### Asynchronous Client
67
+
68
+ ```python
69
+ import asyncio
70
+ from pyrailworks import AsyncRailworksClient
71
+
72
+ async def main():
73
+ async with AsyncRailworksClient() as client:
74
+ health = await client.get_health()
75
+ print("Backend stale:", health.source.stale)
76
+
77
+ async for event in client.iter_changes():
78
+ print("Notice changed:", event.notice_id)
79
+
80
+ asyncio.run(main())
81
+ ```
82
+
83
+ ## Features
84
+
85
+ - **Both Sync & Async**: `RailworksClient` and `AsyncRailworksClient` powered by `httpx`.
86
+ - **Strict Data Validation**: Pydantic v2 data models for type safety, validation, and auto-completion.
87
+ - **Problem Details Handling**: Full support for RFC 9457 errors with specific exceptions (`BadRequestError`, `NotFoundError`, `StationsLoadingError`).
88
+ - **Change Log Streaming**: Helper generators (`iter_changes()`) handling opaque cursor pagination.
89
+ - **Calendar Feeds**: Raw iCalendar text download via `get_calendar_feed()`.
@@ -0,0 +1,67 @@
1
+ # pyrailworks
2
+
3
+ Python client library for the Public RO Railworks API ([https://railworks.paddez.com/docs](https://railworks.paddez.com/docs)).
4
+
5
+ Provides queryable access to Iarnród Éireann's (Irish Rail) planned engineering works, station days, change logs, and iCalendar feeds.
6
+
7
+ ## Installation
8
+
9
+ ```bash
10
+ pip install pyrailworks
11
+ ```
12
+
13
+ ## Quick Start
14
+
15
+ ### Synchronous Client
16
+
17
+ ```python
18
+ from pyrailworks import RailworksClient, LineName
19
+
20
+ with RailworksClient() as client:
21
+ # 1. Health check
22
+ health = client.get_health()
23
+ print("Upstream checked at:", health.source.checked_at)
24
+
25
+ # 2. List stations
26
+ stations = client.list_stations()
27
+ print(f"Total stations: {len(stations)}")
28
+
29
+ # 3. Check affected days for a station
30
+ days_resp = client.get_station_days("WBROK")
31
+ for day in days_resp.days:
32
+ print(f"Station {days_resp.station.name} affected on {day.date}: {day.effect.value}")
33
+
34
+ # 4. List active notices on a line
35
+ notices = client.list_notices(line=LineName.DART, status="active")
36
+ for notice in notices.notices:
37
+ print(f"Notice {notice.id}: {notice.heading} ({notice.starts_on} to {notice.ends_on})")
38
+
39
+ # 5. Follow changes with automatic cursor traversal
40
+ for event in client.iter_changes():
41
+ print(f"Change event: {event.type.value} on notice {event.notice_id}")
42
+ ```
43
+
44
+ ### Asynchronous Client
45
+
46
+ ```python
47
+ import asyncio
48
+ from pyrailworks import AsyncRailworksClient
49
+
50
+ async def main():
51
+ async with AsyncRailworksClient() as client:
52
+ health = await client.get_health()
53
+ print("Backend stale:", health.source.stale)
54
+
55
+ async for event in client.iter_changes():
56
+ print("Notice changed:", event.notice_id)
57
+
58
+ asyncio.run(main())
59
+ ```
60
+
61
+ ## Features
62
+
63
+ - **Both Sync & Async**: `RailworksClient` and `AsyncRailworksClient` powered by `httpx`.
64
+ - **Strict Data Validation**: Pydantic v2 data models for type safety, validation, and auto-completion.
65
+ - **Problem Details Handling**: Full support for RFC 9457 errors with specific exceptions (`BadRequestError`, `NotFoundError`, `StationsLoadingError`).
66
+ - **Change Log Streaming**: Helper generators (`iter_changes()`) handling opaque cursor pagination.
67
+ - **Calendar Feeds**: Raw iCalendar text download via `get_calendar_feed()`.
@@ -0,0 +1,51 @@
1
+ # Domain Docs
2
+
3
+ How the engineering skills should consume this repo's domain documentation when exploring the codebase.
4
+
5
+ ## Before exploring, read these
6
+
7
+ - **`CONTEXT.md`** at the repo root, or
8
+ - **`CONTEXT-MAP.md`** at the repo root if it exists: it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
9
+ - **`docs/adr/`**: read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
10
+
11
+ If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
12
+
13
+ ## File structure
14
+
15
+ Single-context repo (most repos):
16
+
17
+ ```
18
+ /
19
+ ├── CONTEXT.md
20
+ ├── docs/adr/
21
+ │ ├── 0001-event-sourced-orders.md
22
+ │ └── 0002-postgres-for-write-model.md
23
+ └── src/
24
+ ```
25
+
26
+ Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
27
+
28
+ ```
29
+ /
30
+ ├── CONTEXT-MAP.md
31
+ ├── docs/adr/ ← system-wide decisions
32
+ └── src/
33
+ ├── ordering/
34
+ │ ├── CONTEXT.md
35
+ │ └── docs/adr/ ← context-specific decisions
36
+ └── billing/
37
+ ├── CONTEXT.md
38
+ └── docs/adr/
39
+ ```
40
+
41
+ ## Use the glossary's vocabulary
42
+
43
+ When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
44
+
45
+ If the concept you need isn't in the glossary yet, that's a signal: either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
46
+
47
+ ## Flag ADR conflicts
48
+
49
+ If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
50
+
51
+ > _Contradicts ADR-0007 (event-sourced orders), but worth reopening because…_
@@ -0,0 +1,45 @@
1
+ # Issue tracker: GitHub
2
+
3
+ Issues and specs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
4
+
5
+ ## Conventions
6
+
7
+ - **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
8
+ - **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
9
+ - **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
10
+ - **Comment on an issue**: `gh issue comment <number> --body "..."`
11
+ - **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
12
+ - **Close**: `gh issue close <number> --comment "..."`
13
+
14
+ Infer the repo from `git remote -v`; `gh` does this automatically when run inside a clone.
15
+
16
+ ## Pull requests as a triage surface
17
+
18
+ **PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature requests; `/triage` reads this flag.)_
19
+
20
+ When set to `yes`, PRs run through the same labels and states as issues, using the `gh pr` equivalents:
21
+
22
+ - **Read a PR**: `gh pr view <number> --comments` and `gh pr diff <number>` for the diff.
23
+ - **List external PRs for triage**: `gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments` then keep only `authorAssociation` of `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, or `NONE` (drop `OWNER`/`MEMBER`/`COLLABORATOR`).
24
+ - **Comment / label / close**: `gh pr comment`, `gh pr edit --add-label`/`--remove-label`, `gh pr close`.
25
+
26
+ GitHub shares one number space across issues and PRs, so a bare `#42` may be either: resolve with `gh pr view 42` and fall back to `gh issue view 42`.
27
+
28
+ ## When a skill says "publish to the issue tracker"
29
+
30
+ Create a GitHub issue.
31
+
32
+ ## When a skill says "fetch the relevant ticket"
33
+
34
+ Run `gh issue view <number> --comments`.
35
+
36
+ ## Wayfinding operations
37
+
38
+ Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
39
+
40
+ - **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `gh issue create --label wayfinder:map`.
41
+ - **Child ticket**: an issue linked to the map as a GitHub sub-issue (`gh api` on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
42
+ - **Blocking**: GitHub's **native issue dependencies**, the canonical, UI-visible representation. Add an edge with `gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>`, where `<blocker-db-id>` is the blocker's numeric **database id** (`gh api repos/<owner>/<repo>/issues/<n> --jq .id`, _not_ the `#number` or `node_id`). GitHub reports `issue_dependencies_summary.blocked_by` (open blockers only, the live gate). Where dependencies aren't available, fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every blocker is closed.
43
+ - **Frontier query**: list the map's open children (`gh issue list --state open`, scoped to the map's sub-issues / task list), drop any with an open blocker (`issue_dependencies_summary.blocked_by > 0`, or an open issue in the `Blocked by` line) or an assignee; first in map order wins.
44
+ - **Claim**: `gh issue edit <n> --add-assignee @me`, the session's first write.
45
+ - **Resolve**: `gh issue comment <n> --body "<answer>"`, then `gh issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.
@@ -0,0 +1,15 @@
1
+ # Triage Labels
2
+
3
+ The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
4
+
5
+ | Label in mattpocock/skills | Label in our tracker | Meaning |
6
+ | -------------------------- | -------------------- | ---------------------------------------- |
7
+ | `needs-triage` | `needs-triage` | Maintainer needs to evaluate this issue |
8
+ | `needs-info` | `needs-info` | Waiting on reporter for more information |
9
+ | `ready-for-agent` | `ready-for-agent` | Fully specified, ready for an AFK agent |
10
+ | `ready-for-human` | `ready-for-human` | Requires human implementation |
11
+ | `wontfix` | `wontfix` | Will not be actioned |
12
+
13
+ When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
14
+
15
+ Edit the right-hand column to match whatever vocabulary you actually use.
@@ -0,0 +1,38 @@
1
+ [build-system]
2
+ requires = ["hatchling"]
3
+ build-backend = "hatchling.build"
4
+
5
+ [project]
6
+ name = "pyrailworks"
7
+ version = "0.1.0"
8
+ description = "Python client library for the Public RO Railworks Irish Rail Engineering Works API"
9
+ readme = "README.md"
10
+ requires-python = ">=3.10"
11
+ license = "MIT"
12
+ authors = [
13
+ { name = "Irishsmurf" }
14
+ ]
15
+ classifiers = [
16
+ "Programming Language :: Python :: 3",
17
+ "Programming Language :: Python :: 3.10",
18
+ "Programming Language :: Python :: 3.11",
19
+ "Programming Language :: Python :: 3.12",
20
+ "License :: OSI Approved :: MIT License",
21
+ "Operating System :: OS Independent",
22
+ "Typing :: Typed",
23
+ ]
24
+ dependencies = [
25
+ "httpx>=0.24.0",
26
+ "pydantic>=2.0.0",
27
+ ]
28
+
29
+ [project.optional-dependencies]
30
+ dev = [
31
+ "pytest>=8.0.0",
32
+ "pytest-asyncio>=0.23.0",
33
+ "respx>=0.21.0",
34
+ ]
35
+
36
+ [tool.pytest.ini_options]
37
+ asyncio_mode = "auto"
38
+ testpaths = ["tests"]
@@ -0,0 +1,81 @@
1
+ """pyrailworks - Python client for the Public RO Railworks API."""
2
+ from pyrailworks.client import AsyncRailworksClient, RailworksClient
3
+ from pyrailworks.exceptions import (
4
+ BadRequestError,
5
+ NotFoundError,
6
+ ProblemError,
7
+ RailworksError,
8
+ StationsLoadingError,
9
+ )
10
+ from pyrailworks.models import (
11
+ AlterationChange,
12
+ ChangeEvent,
13
+ ChangeEventType,
14
+ ChangesResponse,
15
+ DateInference,
16
+ DateInferenceMethod,
17
+ DaySection,
18
+ Effect,
19
+ EffectKind,
20
+ Extraction,
21
+ ExtractionStatus,
22
+ Health,
23
+ LineName,
24
+ NoticeResponse,
25
+ NoticeStatus,
26
+ NoticesResponse,
27
+ RawNoticeResponse,
28
+ Revision,
29
+ SegmentExpansion,
30
+ ServiceAlteration,
31
+ Source,
32
+ Station,
33
+ StationDay,
34
+ StationDaysResponse,
35
+ StationLine,
36
+ StationResponse,
37
+ StationsResponse,
38
+ TimeScope,
39
+ WorksNotice,
40
+ WorksSegment,
41
+ )
42
+
43
+ __all__ = [
44
+ "RailworksClient",
45
+ "AsyncRailworksClient",
46
+ "RailworksError",
47
+ "ProblemError",
48
+ "BadRequestError",
49
+ "NotFoundError",
50
+ "StationsLoadingError",
51
+ "LineName",
52
+ "NoticeStatus",
53
+ "EffectKind",
54
+ "AlterationChange",
55
+ "ExtractionStatus",
56
+ "DateInferenceMethod",
57
+ "SegmentExpansion",
58
+ "ChangeEventType",
59
+ "Source",
60
+ "DateInference",
61
+ "DaySection",
62
+ "WorksSegment",
63
+ "Effect",
64
+ "ServiceAlteration",
65
+ "Extraction",
66
+ "Revision",
67
+ "WorksNotice",
68
+ "ChangeEvent",
69
+ "StationLine",
70
+ "Station",
71
+ "TimeScope",
72
+ "StationDay",
73
+ "Health",
74
+ "NoticesResponse",
75
+ "NoticeResponse",
76
+ "RawNoticeResponse",
77
+ "ChangesResponse",
78
+ "StationsResponse",
79
+ "StationResponse",
80
+ "StationDaysResponse",
81
+ ]