targetprocess-py 0.2.0__tar.gz → 0.3.0__tar.gz

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/.coderabbit.yaml

@@ -95,7 +95,7 @@ reviews:
     - "!**/uv.lock"
 
   path_instructions:
-    - path: "src/targetprocess/**"
+    - path: "src/targetprocess_py/**"
       instructions: >
         Async Python library for the TargetProcess v1 REST API. TP facts that are
         correct and must not be "fixed": tokens are sent as an access_token query

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/.github/workflows/ci.yml

@@ -32,7 +32,7 @@ jobs:
       - run: uv run ruff check .
       - run: uv run ruff format --check .
       - run: uv run mypy --strict src
-      - run: uv run pytest -q --cov=targetprocess --cov-report=term --cov-fail-under=90
+      - run: uv run pytest -q --cov=targetprocess_py --cov-report=term --cov-fail-under=90
 
   # Runs the same hooks a developer gets locally from `pre-commit install`, so a
   # contributor who skipped the install still meets the same bar, and the hook
@@ -103,4 +103,4 @@ jobs:
           set -euo pipefail
           wheel=$(ls dist/*.whl)
           uv run --isolated --no-project --with "$wheel" python -c \
-            "import targetprocess; print(targetprocess.__version__)"
+            "import targetprocess_py; print(targetprocess_py.__version__)"

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/.github/workflows/release.yml

@@ -47,7 +47,7 @@ jobs:
       - run: uvx twine==7.0.0 check --strict dist/*
       # The version is read from the package, not the tag (see
       # [tool.hatch.version] in pyproject.toml), so a tag that disagrees with
-      # targetprocess.__version__ would publish a release whose files carry a
+      # targetprocess_py.__version__ would publish a release whose files carry a
       # different version from the tag that produced them. Refuse it.
       - name: Assert the tag matches the package version
         env:

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/CHANGELOG.md

@@ -7,6 +7,75 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.3.0] - 2026-09-20
+
+### Changed
+
+- **BREAKING:** the import package is renamed from `targetprocess` to
+  `targetprocess_py`, the PEP 503 normalisation of the distribution name. The
+  distribution is still `targetprocess-py` on PyPI and the repository keeps its
+  name; only the import name changes. An import name that did not match the
+  distribution name made every tool that infers a dependency from a top-level
+  import ask PyPI for a package called `targetprocess`, which does not exist, so
+  such a consumer needed a hand-written override to install this library at all.
+  There is deliberately no compatibility shim: a `targetprocess` module
+  re-exporting the new package would keep alive exactly the import that cannot be
+  resolved. **Migration:** rewrite each `import targetprocess` as
+  `import targetprocess_py`, and each `from targetprocess.<module>` as
+  `from targetprocess_py.<module>`; nothing else about the public surface
+  changes.
+- **BREAKING:** the library's logger namespace is renamed from `targetprocess` to
+  `targetprocess_py`, following the package, so records no longer arrive under a
+  namespace naming a module that does not exist. This fails differently from the
+  import rename and needs its own attention: an import that no longer resolves
+  raises at startup, while logging configuration that no longer matches simply
+  goes silent, with nothing raised to say so. **Migration:** rename
+  `targetprocess` to `targetprocess_py` in every handler, level, filter and
+  `dictConfig` entry that names this library's logger.
+- `list()` refuses a `where=` filter naming the `Assignments` collection on four
+  further collections - `PortfolioEpics`, `TestPlanRuns`, `InboundAssignables`
+  and `OutboundAssignables` - raising `ValueError` before any request is sent,
+  as it already did for the six typed assignable collections. TargetProcess
+  answers such a filter with HTTP 200 and the *unfiltered* rows, so code that
+  appeared to narrow one of these collections by assignee was in fact receiving
+  every row; it now raises rather than returning silently-wrong results. Each
+  collection was confirmed against an unfiltered control on the same collection
+  before being added. Only `list()`'s `where=` is affected - reading
+  `InboundAssignables` or `OutboundAssignables` through `include=` is unchanged.
+- The refusal's message states both ways a path under `Assignments` fails: a
+  filter on one of the collection's fields is accepted and ignored (HTTP 200),
+  while `Assignments.Count` is rejected by the query parser (HTTP 400).
+
+### Fixed
+
+- The eight numeric fields on the `RoleEffort` and `Time` read models no longer
+  carry a `ge=0` bound - `InitialEstimate`, `Effort`, `EffortCompleted`,
+  `EffortToDo`, `TimeSpent` and `TimeRemain` on `RoleEffort`, and `Spent` and
+  `Remain` on `Time`. Each is supplied by the server, and a constraint on a
+  server-supplied value fails the *whole entity* rather than the field, so one
+  out-of-range record would have aborted an entire `list()` page with a
+  `ParseError` - the rule `AssignableEntity` already stated and these two models
+  broke. A consumer relying on `ValidationError` for a negative value on these
+  fields, including on assignment, no longer receives one; `times.upsert` keeps
+  its write-side check, where a range error is actionable.
+- `Time`'s class docstring and its `project` field description say what a
+  custom-activity entry's `project` holds. Such an entry has no `Assignable`,
+  and the field is populated all the same, matching that activity's own project
+  on every entry observed.
+
+## [0.2.1] - 2026-09-18
+
+### Fixed
+
+- A verified clear of a custom field (`update(..., verify=True)` or
+  `set_custom_field(id, name, None)`) no longer raises `VerificationError`
+  when the field reads back `False` or `0`. The re-read comparison now
+  accepts any of TargetProcess's empty-equivalent values - null, `""`,
+  `False` or `0` - as showing a requested clear, rather than only null or
+  `""`. This fixes clearing a `CheckBox` custom field, which reads back
+  `False`, and a numeric one, which reads back `0`; a *set* value of `False`
+  or `0` is unaffected and still compares exactly as before.
+
 ## [0.2.0] - 2026-09-17
 
 The first beta release.
@@ -162,6 +231,8 @@ The first public release.
 - Log scrubbing redacts the `access_token` query parameter and `Authorization`
   header values from the library's own log records.
 
-[Unreleased]: https://github.com/man8/targetprocess-py/compare/v0.2.0...HEAD
+[Unreleased]: https://github.com/man8/targetprocess-py/compare/v0.3.0...HEAD
+[0.3.0]: https://github.com/man8/targetprocess-py/compare/v0.2.1...v0.3.0
+[0.2.1]: https://github.com/man8/targetprocess-py/compare/v0.2.0...v0.2.1
 [0.2.0]: https://github.com/man8/targetprocess-py/compare/v0.1.0...v0.2.0
 [0.1.0]: https://github.com/man8/targetprocess-py/releases/tag/v0.1.0

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/CODEOWNERS

@@ -9,6 +9,6 @@
 # specific approval — not merely any review — is mandatory.
 #
 # If additional maintainers or team-based ownership are added later, split this
-# into per-path rules (e.g. `src/targetprocess/  @man8  @someone`, `.github/  @man8`).
+# into per-path rules (e.g. `src/targetprocess_py/  @man8  @someone`, `.github/  @man8`).
 
 *       @man8

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/CONTRIBUTING.md

@@ -46,7 +46,7 @@ package build run in CI.
 | Lint | `uv run ruff check .` |
 | Format | `uv run ruff format --check .` |
 | Types | `uv run mypy --strict src` |
-| Tests and coverage | `uv run pytest -q --cov=targetprocess --cov-report=term --cov-fail-under=90` |
+| Tests and coverage | `uv run pytest -q --cov=targetprocess_py --cov-report=term --cov-fail-under=90` |
 | Hook suite, commit stage | `uv run pre-commit run --all-files --hook-stage pre-commit` |
 | Hook suite, push stage | `uv run pre-commit run --all-files --hook-stage pre-push` |
 | Commit message | `uv run pre-commit run --hook-stage commit-msg --commit-msg-filename <file>` (CI runs it over the pull request title) |
@@ -297,7 +297,7 @@ feat!: require an explicit mode on the client
 
 A release is a pull request followed by a tag.
 
-1. In a pull request, set `__version__` in `src/targetprocess/__init__.py`
+1. In a pull request, set `__version__` in `src/targetprocess_py/__init__.py`
    (the only version string; the build reads it). Move the `[Unreleased]`
    entries in `CHANGELOG.md` under a `## [X.Y.Z] - YYYY-MM-DD` heading dated
    the release day, and update the link references at its foot. When the minor

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: targetprocess-py
-Version: 0.2.0
+Version: 0.3.0
 Summary: A Python library for the TargetProcess v1 REST API
 Project-URL: Homepage, https://github.com/man8/targetprocess-py
 Project-URL: Repository, https://github.com/man8/targetprocess-py
@@ -75,7 +75,7 @@ For an environment-only install with no project, use `uv pip install targetproce
 ```python
 import asyncio
 
-from targetprocess import ClientMode, TargetProcessClient
+from targetprocess_py import ClientMode, TargetProcessClient
 
 
 async def main() -> None:
@@ -273,7 +273,7 @@ Every library error subclasses `TargetProcessError`, so you can catch a
 specific failure or the base class:
 
 ```python
-from targetprocess import (
+from targetprocess_py import (
     AuthenticationError,
     NotFoundError,
     RateLimitError,
@@ -341,7 +341,7 @@ minor releases; every change is recorded in [CHANGELOG.md](CHANGELOG.md).
    request has been resolved: the library refuses it before sending, verifies it
    after the write, or SPEC.md documents it as a limitation.
 3. The public surface is frozen: SPEC.md's Public API Surface matches
-   `targetprocess.__all__`, a Semantic Versioning promise for that surface is
+   `targetprocess_py.__all__`, a Semantic Versioning promise for that surface is
    stated, and a deprecation policy is written.
 4. Documentation and the recorded test cassettes are current: every public
    resource manager is documented in [docs/USAGE.md](docs/USAGE.md), the

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/README.md

@@ -36,7 +36,7 @@ For an environment-only install with no project, use `uv pip install targetproce
 ```python
 import asyncio
 
-from targetprocess import ClientMode, TargetProcessClient
+from targetprocess_py import ClientMode, TargetProcessClient
 
 
 async def main() -> None:
@@ -234,7 +234,7 @@ Every library error subclasses `TargetProcessError`, so you can catch a
 specific failure or the base class:
 
 ```python
-from targetprocess import (
+from targetprocess_py import (
     AuthenticationError,
     NotFoundError,
     RateLimitError,
@@ -302,7 +302,7 @@ minor releases; every change is recorded in [CHANGELOG.md](CHANGELOG.md).
    request has been resolved: the library refuses it before sending, verifies it
    after the write, or SPEC.md documents it as a limitation.
 3. The public surface is frozen: SPEC.md's Public API Surface matches
-   `targetprocess.__all__`, a Semantic Versioning promise for that surface is
+   `targetprocess_py.__all__`, a Semantic Versioning promise for that surface is
    stated, and a deprecation policy is written.
 4. Documentation and the recorded test cassettes are current: every public
    resource manager is documented in [docs/USAGE.md](docs/USAGE.md), the

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/SECURITY.md

@@ -4,7 +4,8 @@
 
 | Version | Supported |
 | --- | --- |
-| 0.2.x | Yes |
+| 0.3.x | Yes |
+| 0.2.x | No |
 | 0.1.x | No |
 | Pre-release commits before 0.1.0 | No |
 

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/SPEC.md

@@ -85,12 +85,12 @@ itself.
   local `skip` counter, since that can silently skip or repeat records if TP
   ever returns a non-linear continuation URL.
 - **Unrecognised query input**: TP answers a query parameter it does not
-  recognise, and a `where=` naming a nested collection path it does not
-  filter on, with HTTP 200 and the unfiltered, unsorted rows -
-  indistinguishable from success. The confirmed case is a filter on the
-  `Assignments` collection of an assignable, which returns the same rows as
-  the unfiltered request, while the `Assignment` entity's own
-  `GeneralUser.Id` filter applies.
+  recognise, and a `where=` naming a nested collection path it does not filter
+  on, with HTTP 200 and the unfiltered, unsorted rows - indistinguishable from
+  success. The confirmed case is a filter on the `Assignments` collection of an
+  assignable, which returns the same rows as the unfiltered request, while the
+  `Assignment` entity's own `GeneralUser.Id` filter applies. A collection
+  `Count` is the loud exception, rejected with HTTP 400 - `Comments.Count` too.
 - **Bulk endpoint**: writable collections expose
   `POST /api/v1/{collection}/bulk`, taking a JSON array of entity objects -
   an object carrying an `Id` updates that entity, an object without one
@@ -506,10 +506,10 @@ entity back to TP.
 Fields TP computes and returns carry no `ge`/`le` bound. A constraint on a
 server-supplied value fails the **whole entity** rather than the field, so one
 out-of-range roll-up would abort an entire `list()` page with a `ParseError` -
-and TP documents no bounds on effort, progress or flow metrics to assert.
-`RoleEffort` and `Time` keep the bounds they were published with, and
-`times.upsert` validates on the write side, where the value originates and a
-range error is actionable.
+and TP documents no bounds on effort, progress or flow metrics to assert. The
+`RoleEffort` and `Time` join models carry none either; `times.upsert` validates
+on the write side, where the value originates and a range error is actionable.
+The attached-content byte-size fields still carry `ge=0`.
 
 `custom_fields` (`CustomFields`) sits on the `Entity` base, so custom-field
 values are reachable on every entity type: fetched with
@@ -520,10 +520,11 @@ Every typed manager writes one with
 `{"CustomFields": [{"Name": name, "Value": value}]}` through `update`; a null
 `Value` clears. A partial update omitting a custom field keeps its value behind
 a success status, so `verify` defaults on here (off on `update`): the re-read
-matches the entry by name, a clear reading back null or `""`, and raises
-`VerificationError` when the value differs or no entry of that name comes back.
-A date-typed value reads back in wire form, so it verifies only when sent in
-that form (`format_tp_date`) or with `verify=False`.
+matches the entry by name, a clear reading back any of TP's empty-equivalent
+values - null, `""`, `False` or `0`, since a CheckBox reads back `False` and a
+numeric field `0` - and raises `VerificationError` when the value differs or no
+entry of that name comes back. A date-typed value reads back in wire form, so it
+verifies only when sent in that form (`format_tp_date`) or with `verify=False`.
 
 Nested references use one of four lightweight shapes, chosen by what the
 API actually sends:
@@ -687,7 +688,7 @@ at send time, and outside the set; `prettify` stays deliberately absent (see
 above).
 
 **Filter paths.** `BaseResource.ignored_filter_paths` maps the leading segment
-of a `where=` path TP silently ignores on a collection to the reason and the
+of a `where=` path TP will not filter on for a collection to the reason and the
 route to use instead. The known set is declared once, as
 `ASSIGNABLE_IGNORED_FILTER_PATHS` in `resources/base.py`, and referenced by the
 six assignable managers (`UserStory`, `Bug`, `Task`, `Feature`, `Epic`,
@@ -695,7 +696,10 @@ six assignable managers (`UserStory`, `Bug`, `Task`, `Feature`, `Epic`,
 `order_by` or `include` - matching a path's leading segment in any casing
 outside quoted values, and refuses with a `ValueError` naming the collection
 and the route. `entities` mirrors the refusal for every spelling of those six
-collections and for the polymorphic `Assignable` / `Assignables` collection.
+collections and of the untyped Assignable-derived collections confirmed so far -
+`Assignable`, `PortfolioEpic`, `TestPlanRun`, `InboundAssignable` and
+`OutboundAssignable`, in `_UNTYPED_ASSIGNABLE_COLLECTIONS`. That is what has
+been checked, not every candidate; the TestPlan family is unexamined.
 
 | Ignored path | Route instead |
 | --- | --- |
@@ -898,7 +902,7 @@ result = await client.times.upsert(
 
 ## Observability
 
-Runtime observability lives in `targetprocess/_observability.py` and is
+Runtime observability lives in `targetprocess_py/_observability.py` and is
 scoped to what a *library* should own. The application that embeds the
 library owns the rest (metrics, alerting, error tracking, deployment
 observability, product analytics) - it has the deployment context a
@@ -906,17 +910,17 @@ library cannot assume.
 
 ### Implemented signals
 
-- **Structured logging.** A dedicated `logging.getLogger("targetprocess")`
+- **Structured logging.** A dedicated `logging.getLogger("targetprocess_py")`
   with a `NullHandler` by default (silent unless the application attaches a
   handler). `StructuredJsonFormatter` emits one JSON line per record
   (`ts`, `level`, `logger`, `msg`, `request_id`, plus caller extras).
-  `get_logger("name")` returns a child under the `targetprocess` namespace.
+  `get_logger("name")` returns a child under the `targetprocess_py` namespace.
   `RequestHandler._request` emits structured `request.start` /
   `request.complete` / `request.retry` / `request.error` /
   `request.transport_error` records.
 - **Log scrubbing.** `ScrubbingFilter` redacts the `access_token` query
   param and `Authorization: Basic|Bearer` header values from the records
-  this library emits. It is attached to the `targetprocess` logger and to
+  this library emits. It is attached to the `targetprocess_py` logger and to
   every child `get_logger()` returns - both, because a filter on a logger
   runs only for records logged *through* that logger, not for records
   propagated up from a child. It pre-formats and redacts the message, the
@@ -934,7 +938,7 @@ library cannot assume.
   for httpx request-URL logging, *in this library's own records*. The filter
   cannot reach records emitted by other libraries - `httpx` and `httpcore`
   log their own request URLs - nor a logger obtained by calling
-  `logging.getLogger("targetprocess.x")` directly instead of via
+  `logging.getLogger("targetprocess_py.x")` directly instead of via
   `get_logger()`. An application that wants blanket redaction should attach
   a `ScrubbingFilter()` instance to its own handler, which every propagated
   record passes through whatever logger produced it.

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/docs/USAGE.md

@@ -32,7 +32,7 @@ default, so every client declares its safety posture up front.
 ```python
 import asyncio
 
-from targetprocess import ClientMode, TargetProcessClient
+from targetprocess_py import ClientMode, TargetProcessClient
 
 
 async def main() -> None:
@@ -188,7 +188,7 @@ Because the re-read is narrowed, that model carries its `id` and
 `get` the entity again when you need the rest.
 
 ```python
-from targetprocess import VerificationError
+from targetprocess_py import VerificationError
 
 try:
     story = await client.user_stories.update(123, Effort=5, EntityState={"Id": 82}, verify=True)
@@ -245,7 +245,9 @@ story = await client.user_stories.set_custom_field(123, "Release note", None)
 Leaving a field out of an update is not a clear: TargetProcess keeps the old
 value and still answers with a success status. So `set_custom_field` verifies
 by default, re-reading `include=["CustomFields"]` and matching the entry by
-name (case-insensitively); a cleared field may read back as `None` or `""`.
+name (case-insensitively); a cleared field may read back as `None`, `""`,
+`False` or `0` - a CheckBox reads back `False`, and any of these empty
+equivalents counts, regardless of the field's own configured type.
 `VerificationError` here means the value did not land, a clear was discarded,
 or no field of that name exists on the entity's process - a misspelt name, or
 one configured on another process. Pass `verify=False` to skip the re-read.
@@ -582,7 +584,7 @@ custom activity goes through the ordinary `create` and `list`. Send
 the key rather than sending it as `None`:
 
 ```python
-from targetprocess.models import format_tp_date
+from targetprocess_py.models import format_tp_date
 
 entry = await client.times.create(
     CustomActivity={"Id": 42},
@@ -809,7 +811,7 @@ catch a specific failure or the base class. HTTP status codes map to types:
 ```python
 import logging
 
-from targetprocess import (
+from targetprocess_py import (
     AuthenticationError,
     NotFoundError,
     RateLimitError,
@@ -860,7 +862,7 @@ To call the library from otherwise-synchronous code, drive it with
 ```python
 import asyncio
 
-from targetprocess import ClientMode, TargetProcessClient
+from targetprocess_py import ClientMode, TargetProcessClient
 
 
 async def fetch_open_bugs() -> list[str]:
@@ -906,7 +908,7 @@ directly — do not nest `asyncio.run()`.
   attribute assignment, not a hard sandbox.)
 
 ```python
-from targetprocess import ClientMode, ReadOnlyViolation, TargetProcessClient
+from targetprocess_py import ClientMode, ReadOnlyViolation, TargetProcessClient
 
 reporter = TargetProcessClient(
     domain="example.tpondemand.com", token="…", mode=ClientMode.READONLY

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/examples/bulk_updates.py

@@ -41,7 +41,7 @@ import asyncio
 import os
 import sys
 
-from targetprocess import ClientMode, TargetProcessClient, TargetProcessError
+from targetprocess_py import ClientMode, TargetProcessClient, TargetProcessError
 
 MARKER = "Bulk-updated by the targetprocess-py bulk_updates example."
 

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/examples/create_bug.py

@@ -35,7 +35,7 @@ import asyncio
 import os
 import sys
 
-from targetprocess import ClientMode, TargetProcessClient, TargetProcessError
+from targetprocess_py import ClientMode, TargetProcessClient, TargetProcessError
 
 
 def _env(name: str) -> str:

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/examples/list_user_stories.py

@@ -24,7 +24,7 @@ import asyncio
 import os
 import sys
 
-from targetprocess import ClientMode, TargetProcessClient, TargetProcessError
+from targetprocess_py import ClientMode, TargetProcessClient, TargetProcessError
 
 
 def _env(name: str) -> str:

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/examples/readonly_reporting.py

@@ -25,7 +25,7 @@ import os
 import sys
 from collections import Counter
 
-from targetprocess import ClientMode, TargetProcessClient, TargetProcessError
+from targetprocess_py import ClientMode, TargetProcessClient, TargetProcessError
 
 
 def _env(name: str) -> str:

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "targetprocess-py"
-# Single source of truth is targetprocess.__version__; hatchling reads it at
+# Single source of truth is targetprocess_py.__version__; hatchling reads it at
 # build time (see [tool.hatch.version]), so a release bumps that one string.
 dynamic = ["version"]
 description = "A Python library for the TargetProcess v1 REST API"
@@ -65,10 +65,10 @@ Changelog = "https://github.com/man8/targetprocess-py/blob/main/CHANGELOG.md"
 Issues = "https://github.com/man8/targetprocess-py/issues"
 
 [tool.hatch.version]
-path = "src/targetprocess/__init__.py"
+path = "src/targetprocess_py/__init__.py"
 
 [tool.hatch.build.targets.wheel]
-packages = ["src/targetprocess"]
+packages = ["src/targetprocess_py"]
 
 [tool.pytest.ini_options]
 asyncio_mode = "auto"
@@ -142,7 +142,7 @@ max-complexity = 10
 # CustomFields, Name) deliberately mirror the wire format the TP API returns,
 # so N802's lowercase rule does not apply to them. They live on the Entity /
 # NamedEntity bases in _base.py; models.py is the re-export surface.
-"src/targetprocess/_base.py" = ["N802"]
+"src/targetprocess_py/_base.py" = ["N802"]
 
 [tool.coverage.run]
 source = ["src"]

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/scripts/check_model_coverage.py

@@ -43,8 +43,8 @@ from typing import TYPE_CHECKING, Any, NamedTuple
 
 sys.path.insert(0, str(Path(__file__).resolve().parent.parent / "src"))
 
-from targetprocess import models, resources  # noqa: E402
-from targetprocess.resources.base import BaseResource  # noqa: E402
+from targetprocess_py import models, resources  # noqa: E402
+from targetprocess_py.resources.base import BaseResource  # noqa: E402
 
 if TYPE_CHECKING:  # pragma: no cover - import-time typing only
     from pydantic import BaseModel

{targetprocess_py-0.2.0 → targetprocess_py-0.3.0}/scripts/live_smoke.py

@@ -42,7 +42,7 @@ from pathlib import Path
 from typing import Any
 from urllib.parse import urlparse
 
-from targetprocess import ClientMode, ReadOnlyViolation, TargetProcessClient
+from targetprocess_py import ClientMode, ReadOnlyViolation, TargetProcessClient
 
 ENV_FILE = Path.home() / ".config" / "targetprocess" / ".env"
 

{targetprocess_py-0.2.0/src/targetprocess → targetprocess_py-0.3.0/src/targetprocess_py}/__init__.py

@@ -1,6 +1,6 @@
 """A Python library for the TargetProcess v1 REST API."""
 
-from targetprocess._observability import (
+from targetprocess_py._observability import (
     REQUEST_ID_HEADER,
     ScrubbingFilter,
     StructuredJsonFormatter,
@@ -9,8 +9,8 @@ from targetprocess._observability import (
     new_request_id,
     request_id_context,
 )
-from targetprocess.client import TargetProcessClient
-from targetprocess.exceptions import (
+from targetprocess_py.client import TargetProcessClient
+from targetprocess_py.exceptions import (
     AmbiguousMatchError,
     APIError,
     AuthenticationError,
@@ -25,7 +25,7 @@ from targetprocess.exceptions import (
     TargetProcessError,
     VerificationError,
 )
-from targetprocess.models import (
+from targetprocess_py.models import (
     AssignableEntity,
     Assignment,
     Attachment,
@@ -71,8 +71,8 @@ from targetprocess.models import (
     UserStory,
     Workflow,
 )
-from targetprocess.request_handler import RequestHandler
-from targetprocess.resources import (
+from targetprocess_py.request_handler import RequestHandler
+from targetprocess_py.resources import (
     AssignableResource,
     AssignmentsResource,
     AttachmentsResource,
@@ -109,10 +109,10 @@ from targetprocess.resources import (
     UserStoriesResource,
     WorkflowsResource,
 )
-from targetprocess.response_parser import ResponseParser
-from targetprocess.types import ClientMode, LevelState, StateLevels, UpsertAction, UpsertResult
+from targetprocess_py.response_parser import ResponseParser
+from targetprocess_py.types import ClientMode, LevelState, StateLevels, UpsertAction, UpsertResult
 
-__version__ = "0.2.0"
+__version__ = "0.3.0"
 
 __all__ = [
     # Exceptions

{targetprocess_py-0.2.0/src/targetprocess → targetprocess_py-0.3.0/src/targetprocess_py}/_assignables.py

@@ -2,19 +2,19 @@
 
 Everything these share - effort, flow metrics, planning references, workflow
 state, assigned users - is declared once on
-:class:`targetprocess._base.AssignableEntity`. Each class below adds only what
+:class:`targetprocess_py._base.AssignableEntity`. Each class below adds only what
 TP's ``/meta`` declares beyond that base for its own type. ``InitialEstimate``
 and ``Build`` recur but are deliberately not on the base: TP gives Task and Bug
 no ``InitialEstimate``, and Task no ``Build``.
 
-Re-exported by :mod:`targetprocess.models`, which stays the import surface
+Re-exported by :mod:`targetprocess_py.models`, which stays the import surface
 callers use.
 """
 
 from pydantic import Field
 
-from targetprocess._base import AssignableEntity
-from targetprocess._nested import EntityRef, RefWithImportance
+from targetprocess_py._base import AssignableEntity
+from targetprocess_py._nested import EntityRef, RefWithImportance
 
 
 class UserStory(AssignableEntity):

{targetprocess_py-0.2.0/src/targetprocess → targetprocess_py-0.3.0/src/targetprocess_py}/_base.py

@@ -12,7 +12,7 @@ counterpart - they hold the identity fields every payload shares and the
 lookup and join types) have a base too.
 
 The concrete entity models live in the sibling private modules and are
-re-exported by :mod:`targetprocess.models`, which stays the import surface
+re-exported by :mod:`targetprocess_py.models`, which stays the import surface
 callers use.
 """
 
@@ -20,8 +20,8 @@ from datetime import datetime
 
 from pydantic import BaseModel, ConfigDict, Field
 
-from targetprocess._dates import TPDateTime
-from targetprocess._nested import (
+from targetprocess_py._dates import TPDateTime
+from targetprocess_py._nested import (
     AssignedUsers,
     CustomFieldValue,
     EntityRef,

{targetprocess_py-0.2.0/src/targetprocess → targetprocess_py-0.3.0/src/targetprocess_py}/_content.py

@@ -4,15 +4,15 @@ A ``Comment`` and an ``Attachment`` both hang off a ``General``; a
 ``CustomField`` describes a field configured on a process rather than a value
 held by an entity. None sits in TP's ``General`` hierarchy.
 
-Re-exported by :mod:`targetprocess.models`, which stays the import surface
+Re-exported by :mod:`targetprocess_py.models`, which stays the import surface
 callers use.
 """
 
 from pydantic import BaseModel, ConfigDict, Field
 
-from targetprocess._base import Entity, NamedEntity
-from targetprocess._dates import TPDateTime
-from targetprocess._nested import CustomFieldConfig, EntityRef, EntityTypeRef, UserRef
+from targetprocess_py._base import Entity, NamedEntity
+from targetprocess_py._dates import TPDateTime
+from targetprocess_py._nested import CustomFieldConfig, EntityRef, EntityTypeRef, UserRef
 
 
 class Comment(Entity):

{targetprocess_py-0.2.0/src/targetprocess → targetprocess_py-0.3.0/src/targetprocess_py}/_dates.py

@@ -1,7 +1,7 @@
 """TP ``/Date(ms±HHMM)/`` wire-format date handling.
 
 The public names here (``TPDateTime``, ``parse_tp_date``, ``format_tp_date``)
-are re-exported by :mod:`targetprocess.models`, which remains the import
+are re-exported by :mod:`targetprocess_py.models`, which remains the import
 surface callers use.
 """