meterbase 0.1.2__tar.gz → 0.1.3__tar.gz

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: meterbase
-Version: 0.1.2
+Version: 0.1.3
 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
@@ -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.3}/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
@@ -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.3/src/meterbase/_version.py

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

meterbase-0.1.2/src/meterbase/_version.py

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