meterbase 0.1.2__tar.gz → 0.1.4__tar.gz

{meterbase-0.1.2 → meterbase-0.1.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: meterbase
-Version: 0.1.2
+Version: 0.1.4
 Summary: Python SDK for the Meterbase engine
 Project-URL: Homepage, https://meterbase.tech
 Project-URL: Documentation, https://meterbase.tech/docs
@@ -72,8 +72,10 @@ meterbase.track(
 )
 ```
 
-An API key names its own workspace, so there is no workspace to pass. Create
-one client and reuse it: it keeps a pool of connections open, and
+An API key names its own workspace, so there is no workspace to pass. A
+sandbox's keys start `mb_sk_test_` and act on the sandbox alone, so give
+development, CI and staging one of those: nothing else in your code changes.
+Create one client and reuse it: it keeps a pool of connections open, and
 `meterbase.close()` — or a `with` block — closes them.
 
 `check` is the gate, and the only call that ever refuses. It never raises for a
@@ -776,7 +778,7 @@ SDK would raise for a response, for realistic errors in your own tests.
 Meterbase(
     api_key="mb_sk_live_…",
     base_url="https://api.meterbase.dev",
-    timeout=10.0,  # seconds, per attempt
+    timeout=35.0,  # seconds, per attempt
     max_retries=2,
     http_client=httpx.Client(proxy="http://localhost:8030"),  # yours to close
 )
@@ -886,7 +888,8 @@ schedule, cancel and re-anchor as documented; and — reading each model's
 annotations — that the engine's fields still match the SDK's types exactly, in
 both directions.
 
-> **It creates and deletes real data.** Point it at a test workspace. It only
+> **It creates and deletes real data.** Point it at a sandbox, with an
+> `mb_sk_test_` key. It only
 > touches resources it created, tagging each with a per-run id, and cleans up
 > afterwards; soft-deleted customers and archived meters and plans remain, as
 > the engine intends. It is outside `make test` on purpose — a mutating suite

{meterbase-0.1.2 → meterbase-0.1.4}/README.md

@@ -45,8 +45,10 @@ meterbase.track(
 )
 ```
 
-An API key names its own workspace, so there is no workspace to pass. Create
-one client and reuse it: it keeps a pool of connections open, and
+An API key names its own workspace, so there is no workspace to pass. A
+sandbox's keys start `mb_sk_test_` and act on the sandbox alone, so give
+development, CI and staging one of those: nothing else in your code changes.
+Create one client and reuse it: it keeps a pool of connections open, and
 `meterbase.close()` — or a `with` block — closes them.
 
 `check` is the gate, and the only call that ever refuses. It never raises for a
@@ -749,7 +751,7 @@ SDK would raise for a response, for realistic errors in your own tests.
 Meterbase(
     api_key="mb_sk_live_…",
     base_url="https://api.meterbase.dev",
-    timeout=10.0,  # seconds, per attempt
+    timeout=35.0,  # seconds, per attempt
     max_retries=2,
     http_client=httpx.Client(proxy="http://localhost:8030"),  # yours to close
 )
@@ -859,7 +861,8 @@ schedule, cancel and re-anchor as documented; and — reading each model's
 annotations — that the engine's fields still match the SDK's types exactly, in
 both directions.
 
-> **It creates and deletes real data.** Point it at a test workspace. It only
+> **It creates and deletes real data.** Point it at a sandbox, with an
+> `mb_sk_test_` key. It only
 > touches resources it created, tagging each with a per-run id, and cleans up
 > afterwards; soft-deleted customers and archived meters and plans remain, as
 > the engine intends. It is outside `make test` on purpose — a mutating suite

{meterbase-0.1.2 → meterbase-0.1.4}/src/meterbase/_http.py

@@ -23,7 +23,7 @@ from ._version import __version__
 from .errors import APIError, MeterbaseError, error_from_response
 
 DEFAULT_BASE_URL = "https://api.meterbase.tech"
-DEFAULT_TIMEOUT = 10.0
+DEFAULT_TIMEOUT = 35.0
 DEFAULT_MAX_RETRIES = 2
 MAX_BACKOFF = 8.0
 

meterbase-0.1.4/src/meterbase/_version.py

@@ -0,0 +1 @@
+__version__ = "0.1.4"

meterbase-0.1.2/src/meterbase/_version.py

@@ -1 +0,0 @@
-__version__ = "0.1.2"