robotframework-parallelrunner 0.3.1__tar.gz → 0.5.0__tar.gz

{robotframework_parallelrunner-0.3.1 → robotframework_parallelrunner-0.5.0}/PKG-INFO

@@ -1,20 +1,19 @@
 Metadata-Version: 2.4
 Name: robotframework-parallelrunner
-Version: 0.3.1
+Version: 0.5.0
 Summary: Run a keyword in parallel inside a single Robot Framework test case, with one clean, ordered log.html.
 License-Expression: MIT
 License-File: LICENSE
 Keywords: robotframework,robot-framework,parallel,threading,testing,automation
 Author: Cristian Garcia
 Author-email: cristian.garcia.vd@gmail.com
-Requires-Python: >=3.9
+Requires-Python: >=3.10
 Classifier: Development Status :: 4 - Beta
 Classifier: Framework :: Robot Framework
 Classifier: Framework :: Robot Framework :: Library
 Classifier: Intended Audience :: Developers
 Classifier: Operating System :: OS Independent
 Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.9
 Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
@@ -53,9 +52,10 @@ correctly ordered `log.html` plus a structured list of per-item results.
 pip install robotframework-parallelrunner
 ```
 
-Requires Python 3.9+ and Robot Framework 5.0+ (installed automatically).
-See [docs/INSTALLATION.md](https://github.com/cristiangarciavd/robotframework-parallelrunner/blob/main/docs/INSTALLATION.md) for development installs
-and upgrading from the pre-release import path.
+Requires Python 3.10+ and Robot Framework 5.0+ (installed automatically).
+See [docs/INSTALLATION.md](https://github.com/cristiangarciavd/robotframework-parallelrunner/blob/main/docs/INSTALLATION.md) for development installs,
+upgrading from the pre-release import path, and Python 3.8/3.9 (no longer
+supported, but 0.5.0 was tested and works on them).
 
 ## Quickstart
 
@@ -113,8 +113,8 @@ threading, buffering, and replay logic stay out of your `.robot` files.
 ## Summary of Benefits
 
 - **Speed.** Waiting time is overlapped instead of added up. In this repo's
-  examples, 9 HTTP checks with a 1 s delay each drop from 13 s to 2 s with
-  9 workers, and 4 suites × 8 items × 1 s drop from 32.7 s to 4.6 s with
+  examples, 9 HTTP checks with a 1 s delay each drop from 13.9 s to 2.2 s with
+  9 workers, and 4 suites × 8 items × 1 s drop from 32.9 s to 5.1 s with
   8 workers (see [Using It Together With pabot](#using-it-together-with-pabot)).
 - **Integrity.** Your `log.html` remains the single source of truth — no
   broken XML tags from concurrent writes.
@@ -183,7 +183,7 @@ pabot --processes 4 --pythonpath . atest/
 pabot --processes 4 --testlevelsplit --pythonpath . atest/
 ```
 
-Both commands pass the full acceptance suite of this repository (52 tests;
+Both commands pass the full acceptance suite of this repository (82 tests;
 checked with pabot 5.2.2).
 
 How much time each one saves, from the offline
@@ -192,14 +192,14 @@ How much time each one saves, from the offline
 
 | Run | Wall-clock time | Speedup |
 |---|---|---|
-| robot, sequential loop | 32.7 s | ×1.0 |
-| robot + ParallelRunner (8 workers) | 4.6 s | ×7.1 |
-| pabot (4 processes), sequential loop | 10.6 s | ×3.1 |
-| pabot (4 processes) + ParallelRunner (8 workers) | 3.5 s | ×9.2 |
+| robot, sequential loop | 32.9 s | ×1.0 |
+| robot + ParallelRunner (8 workers) | 5.1 s | ×6.5 |
+| pabot (4 processes), sequential loop | 12.4 s | ×2.7 |
+| pabot (4 processes) + ParallelRunner (8 workers) | 4.6 s | ×7.2 |
 
 ParallelRunner removes the waiting *inside* each test, and pabot removes it
 *between* suites. With suites this short, pabot's process start-up (about
-2.5 s here) is most of what's left, so the combination pays off more as
+3.5 s here) is most of what's left, so the combination pays off more as
 suites get longer.
 
 Things to keep in mind:
@@ -221,6 +221,31 @@ Things to keep in mind:
   could interfere with each other. Keep shared state per process, or split
   by suite.
 
+## How Is This Different From AsyncLibrary?
+
+[AsyncLibrary](https://github.com/rlehfeld/robotframework-async-keyword)
+(`pip install robotframework-async-keyword`) also runs keywords in threads
+inside one test case. It runs *any* keyword, user keywords included: you
+start each call with `Async Run` and collect it later with `Async Get`. It
+buffers each call's output and replays it, so `log.html` keeps the full
+nested keyword structure. To do that, it works with Robot Framework's
+internal execution context and output.
+
+| | **AsyncLibrary** | **ParallelRunner** |
+|---|---|---|
+| Runs | Any keyword, including user keywords | A method of a Python library that accepts `_logger` |
+| Usage | `Async Run` per call, `Async Get` later | One `Run Parallel Scenarios` call over a list, or `repeat=N` |
+| Concurrency | Python's default thread pool size | `ROBOT_THREAD_WORKERS` |
+| Hung calls | `Async Get    timeout=...` stops waiting for them | `call_timeout` fails only that call and frees its slot for the next item |
+| Failures | `Async Get` raises the call's error | One failure listing every failed item, or a `PASS`/`FAIL` per item with `fail_on_error=False` |
+| Robot internals | Works with the internal execution context and output | Not patched; logs only from the main thread, through the public logger API; tested on Robot Framework 5, 6 and 7 |
+
+Use AsyncLibrary when the work lives in user keywords (or in library
+keywords you can't change), or when you want to start something in the
+background, run other steps, and collect it later. Use ParallelRunner to fan
+one Python keyword out over many items as a single batch, with a bounded
+worker pool, per-call timeouts and one failure report for the whole batch.
+
 ## When Not To Use This
 
 - **CPU-bound work.** Threads share Python's GIL — number crunching won't
@@ -230,11 +255,6 @@ Things to keep in mind:
   made thread-safe for you; your own keyword's side effects are not. If it
   writes to a shared variable, file, or object without a lock, running it
   concurrently can race the same way any multi-threaded code can.
-- **You need per-item retries or a per-item timeout.** Not implemented yet
-  (see [ROADMAP.md](https://github.com/cristiangarciavd/robotframework-parallelrunner/blob/main/ROADMAP.md)). A Robot `[Timeout]` on the test or keyword does
-  interrupt the whole batch when it expires and replays the logs collected so
-  far, but calls that are already running can't be stopped: they keep running
-  in the background until they return.
 - **You need process-level isolation** (a crash in one call shouldn't be
   able to affect another) or cross-machine parallelism — that's pabot's
   domain, not this library's.

{robotframework_parallelrunner-0.3.1 → robotframework_parallelrunner-0.5.0}/README.md

@@ -19,9 +19,10 @@ correctly ordered `log.html` plus a structured list of per-item results.
 pip install robotframework-parallelrunner
 ```
 
-Requires Python 3.9+ and Robot Framework 5.0+ (installed automatically).
-See [docs/INSTALLATION.md](https://github.com/cristiangarciavd/robotframework-parallelrunner/blob/main/docs/INSTALLATION.md) for development installs
-and upgrading from the pre-release import path.
+Requires Python 3.10+ and Robot Framework 5.0+ (installed automatically).
+See [docs/INSTALLATION.md](https://github.com/cristiangarciavd/robotframework-parallelrunner/blob/main/docs/INSTALLATION.md) for development installs,
+upgrading from the pre-release import path, and Python 3.8/3.9 (no longer
+supported, but 0.5.0 was tested and works on them).
 
 ## Quickstart
 
@@ -79,8 +80,8 @@ threading, buffering, and replay logic stay out of your `.robot` files.
 ## Summary of Benefits
 
 - **Speed.** Waiting time is overlapped instead of added up. In this repo's
-  examples, 9 HTTP checks with a 1 s delay each drop from 13 s to 2 s with
-  9 workers, and 4 suites × 8 items × 1 s drop from 32.7 s to 4.6 s with
+  examples, 9 HTTP checks with a 1 s delay each drop from 13.9 s to 2.2 s with
+  9 workers, and 4 suites × 8 items × 1 s drop from 32.9 s to 5.1 s with
   8 workers (see [Using It Together With pabot](#using-it-together-with-pabot)).
 - **Integrity.** Your `log.html` remains the single source of truth — no
   broken XML tags from concurrent writes.
@@ -149,7 +150,7 @@ pabot --processes 4 --pythonpath . atest/
 pabot --processes 4 --testlevelsplit --pythonpath . atest/
 ```
 
-Both commands pass the full acceptance suite of this repository (52 tests;
+Both commands pass the full acceptance suite of this repository (82 tests;
 checked with pabot 5.2.2).
 
 How much time each one saves, from the offline
@@ -158,14 +159,14 @@ How much time each one saves, from the offline
 
 | Run | Wall-clock time | Speedup |
 |---|---|---|
-| robot, sequential loop | 32.7 s | ×1.0 |
-| robot + ParallelRunner (8 workers) | 4.6 s | ×7.1 |
-| pabot (4 processes), sequential loop | 10.6 s | ×3.1 |
-| pabot (4 processes) + ParallelRunner (8 workers) | 3.5 s | ×9.2 |
+| robot, sequential loop | 32.9 s | ×1.0 |
+| robot + ParallelRunner (8 workers) | 5.1 s | ×6.5 |
+| pabot (4 processes), sequential loop | 12.4 s | ×2.7 |
+| pabot (4 processes) + ParallelRunner (8 workers) | 4.6 s | ×7.2 |
 
 ParallelRunner removes the waiting *inside* each test, and pabot removes it
 *between* suites. With suites this short, pabot's process start-up (about
-2.5 s here) is most of what's left, so the combination pays off more as
+3.5 s here) is most of what's left, so the combination pays off more as
 suites get longer.
 
 Things to keep in mind:
@@ -187,6 +188,31 @@ Things to keep in mind:
   could interfere with each other. Keep shared state per process, or split
   by suite.
 
+## How Is This Different From AsyncLibrary?
+
+[AsyncLibrary](https://github.com/rlehfeld/robotframework-async-keyword)
+(`pip install robotframework-async-keyword`) also runs keywords in threads
+inside one test case. It runs *any* keyword, user keywords included: you
+start each call with `Async Run` and collect it later with `Async Get`. It
+buffers each call's output and replays it, so `log.html` keeps the full
+nested keyword structure. To do that, it works with Robot Framework's
+internal execution context and output.
+
+| | **AsyncLibrary** | **ParallelRunner** |
+|---|---|---|
+| Runs | Any keyword, including user keywords | A method of a Python library that accepts `_logger` |
+| Usage | `Async Run` per call, `Async Get` later | One `Run Parallel Scenarios` call over a list, or `repeat=N` |
+| Concurrency | Python's default thread pool size | `ROBOT_THREAD_WORKERS` |
+| Hung calls | `Async Get    timeout=...` stops waiting for them | `call_timeout` fails only that call and frees its slot for the next item |
+| Failures | `Async Get` raises the call's error | One failure listing every failed item, or a `PASS`/`FAIL` per item with `fail_on_error=False` |
+| Robot internals | Works with the internal execution context and output | Not patched; logs only from the main thread, through the public logger API; tested on Robot Framework 5, 6 and 7 |
+
+Use AsyncLibrary when the work lives in user keywords (or in library
+keywords you can't change), or when you want to start something in the
+background, run other steps, and collect it later. Use ParallelRunner to fan
+one Python keyword out over many items as a single batch, with a bounded
+worker pool, per-call timeouts and one failure report for the whole batch.
+
 ## When Not To Use This
 
 - **CPU-bound work.** Threads share Python's GIL — number crunching won't
@@ -196,11 +222,6 @@ Things to keep in mind:
   made thread-safe for you; your own keyword's side effects are not. If it
   writes to a shared variable, file, or object without a lock, running it
   concurrently can race the same way any multi-threaded code can.
-- **You need per-item retries or a per-item timeout.** Not implemented yet
-  (see [ROADMAP.md](https://github.com/cristiangarciavd/robotframework-parallelrunner/blob/main/ROADMAP.md)). A Robot `[Timeout]` on the test or keyword does
-  interrupt the whole batch when it expires and replays the logs collected so
-  far, but calls that are already running can't be stopped: they keep running
-  in the background until they return.
 - **You need process-level isolation** (a crash in one call shouldn't be
   able to affect another) or cross-machine parallelism — that's pabot's
   domain, not this library's.

{robotframework_parallelrunner-0.3.1 → robotframework_parallelrunner-0.5.0}/pyproject.toml

@@ -6,12 +6,12 @@ build-backend = "poetry.core.masonry.api"
 name = "robotframework-parallelrunner"
 # Single source of truth for the version: bump with `poetry version patch|minor|major`.
 # ParallelRunner.__version__ / ROBOT_LIBRARY_VERSION read it back from the installed metadata.
-version = "0.3.1"
+version = "0.5.0"
 description = "Run a keyword in parallel inside a single Robot Framework test case, with one clean, ordered log.html."
 readme = "README.md"
 license = "MIT"
 license-files = ["LICENSE"]
-requires-python = ">=3.9"
+requires-python = ">=3.10"
 authors = [
     { name = "Cristian Garcia", email = "cristian.garcia.vd@gmail.com" },
 ]
@@ -30,7 +30,6 @@ classifiers = [
     "Intended Audience :: Developers",
     "Operating System :: OS Independent",
     "Programming Language :: Python :: 3",
-    "Programming Language :: Python :: 3.9",
     "Programming Language :: Python :: 3.10",
     "Programming Language :: Python :: 3.11",
     "Programming Language :: Python :: 3.12",

{robotframework_parallelrunner-0.3.1 → robotframework_parallelrunner-0.5.0}/src/ParallelRunner/__init__.py

@@ -13,7 +13,7 @@ Keyword documentation:
 https://cristiangarciavd.github.io/robotframework-parallelrunner/ParallelRunner.html
 """
 
-from .parallel_library import ParallelLibrary, ParallelRunner, ParallelTaskError
+from .parallel_library import ParallelLibrary, ParallelRunner, ParallelTaskError, log_to_robot
 from .version import __version__
 
-__all__ = ["ParallelRunner", "ParallelLibrary", "ParallelTaskError", "__version__"]
+__all__ = ["ParallelRunner", "ParallelLibrary", "ParallelTaskError", "log_to_robot", "__version__"]