unitysvc-data 0.2.4__tar.gz → 0.2.5__tar.gz

{unitysvc_data-0.2.4/src/unitysvc_data.egg-info → unitysvc_data-0.2.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: unitysvc-data
-Version: 0.2.4
+Version: 0.2.5
 Summary: Standard examples and presets for UnitySVC data packages
 Author-email: Bo Peng <bo.peng@unitysvc.com>
 Maintainer-email: Bo Peng <bo.peng@unitysvc.com>

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "unitysvc-data"
-version = "0.2.4"
+version = "0.2.5"
 description = "Standard examples and presets for UnitySVC data packages"
 readme = "README.md"
 authors = [{ name = "Bo Peng", email = "bo.peng@unitysvc.com" }]

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-connectivity/README.md

@@ -26,6 +26,11 @@ are one wire dialect, and a service must say which of the two it speaks. Neither
 is the default; a group naming a bare `dashscope` selects neither, which fails
 where it can be seen rather than sending the wrong shape.
 
+The request pins `parameters.result_format` to `"message"`. Text-generation
+returns whichever shape the MODEL defaults to otherwise — `output.text` for some,
+`output.choices[].message` for others — and a reader cannot be written against
+both. Pinning it makes the response shape a property of the request.
+
 Assertions check the payload rather than the status, because DashScope answers
 **200 with an error envelope**. They sit behind `{%- if not customer_display %}`
 so the published example stays clean.
@@ -36,3 +41,11 @@ so the published example stays clean.
 
 - The smallest useful request the text-generation endpoint takes.
 - Asserts the reply carries `"choices"`; a 2xx alone is not enough.
+- **Amended in 0.2.5**: `parameters.result_format` is now pinned to `"message"`.
+  Without it DashScope's text-generation returns whichever shape the MODEL
+  defaults to — `output.text` for some, `output.choices[].message` for others —
+  so an example that reads `choices` failed on half the catalog with
+  `Cannot read properties of undefined`. Probed both ways on `qwen-flash`:
+  absent gives `{"output":{"text":…}}`, `"message"` gives
+  `{"output":{"choices":[…]}}`. The reader is unchanged; the request now asks for
+  the shape it reads.

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-connectivity/connectivity-v1.sh.j2

@@ -9,7 +9,7 @@ set -e -o pipefail
 response=$(curl --fail-with-body -sS "{{ service_base_url }}" \
   -H "Content-Type: application/json" \
   -H "Authorization: Bearer ${UNITYSVC_API_KEY}" \
-  -d '{"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64}}')
+  -d '{"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64, "result_format": "message"}}')
 
 echo "$response"
 {%- if not customer_display %}

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-javascript/README.md

@@ -26,6 +26,11 @@ are one wire dialect, and a service must say which of the two it speaks. Neither
 is the default; a group naming a bare `dashscope` selects neither, which fails
 where it can be seen rather than sending the wrong shape.
 
+The request pins `parameters.result_format` to `"message"`. Text-generation
+returns whichever shape the MODEL defaults to otherwise — `output.text` for some,
+`output.choices[].message` for others — and a reader cannot be written against
+both. Pinning it makes the response shape a property of the request.
+
 Assertions check the payload rather than the status, because DashScope answers
 **200 with an error envelope**. They sit behind `{%- if not customer_display %}`
 so the published example stays clean.
@@ -35,3 +40,11 @@ so the published example stays clean.
 ### v1 — initial release
 
 - `fetch`, no SDK; throws with the response body on a non-2xx.
+- **Amended in 0.2.5**: `parameters.result_format` is now pinned to `"message"`.
+  Without it DashScope's text-generation returns whichever shape the MODEL
+  defaults to — `output.text` for some, `output.choices[].message` for others —
+  so an example that reads `choices` failed on half the catalog with
+  `Cannot read properties of undefined`. Probed both ways on `qwen-flash`:
+  absent gives `{"output":{"text":…}}`, `"message"` gives
+  `{"output":{"choices":[…]}}`. The reader is unchanged; the request now asks for
+  the shape it reads.

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-javascript/code-example-v1.js.j2

@@ -5,7 +5,7 @@ async function main() {
       "Content-Type": "application/json",
       Authorization: `Bearer ${process.env.UNITYSVC_API_KEY}`,
     },
-    body: JSON.stringify({"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64}}),
+    body: JSON.stringify({"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64, "result_format": "message"}}),
   });
   if (!response.ok) {
     throw new Error(`HTTP ${response.status}: ${await response.text()}`);

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-requests/README.md

@@ -26,6 +26,11 @@ are one wire dialect, and a service must say which of the two it speaks. Neither
 is the default; a group naming a bare `dashscope` selects neither, which fails
 where it can be seen rather than sending the wrong shape.
 
+The request pins `parameters.result_format` to `"message"`. Text-generation
+returns whichever shape the MODEL defaults to otherwise — `output.text` for some,
+`output.choices[].message` for others — and a reader cannot be written against
+both. Pinning it makes the response shape a property of the request.
+
 Assertions check the payload rather than the status, because DashScope answers
 **200 with an error envelope**. They sit behind `{%- if not customer_display %}`
 so the published example stays clean.
@@ -38,3 +43,11 @@ so the published example stays clean.
 - No vendor SDK; `requests` only.
 - Raises with the response body on a non-2xx, rather than `raise_for_status`,
   which discards it.
+- **Amended in 0.2.5**: `parameters.result_format` is now pinned to `"message"`.
+  Without it DashScope's text-generation returns whichever shape the MODEL
+  defaults to — `output.text` for some, `output.choices[].message` for others —
+  so an example that reads `choices` failed on half the catalog with
+  `Cannot read properties of undefined`. Probed both ways on `qwen-flash`:
+  absent gives `{"output":{"text":…}}`, `"message"` gives
+  `{"output":{"choices":[…]}}`. The reader is unchanged; the request now asks for
+  the shape it reads.

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-requests/code-example-v1.py.j2

@@ -8,7 +8,7 @@ response = requests.post(
         "Authorization": f"Bearer {os.environ['UNITYSVC_API_KEY']}",
         "Content-Type": "application/json",
     },
-    json={"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64}},
+    json={"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64, "result_format": "message"}},
 )
 if response.status_code >= 400:
     raise RuntimeError(f"HTTP {response.status_code} from {response.url}: {response.text}")

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-shell/README.md

@@ -26,6 +26,11 @@ are one wire dialect, and a service must say which of the two it speaks. Neither
 is the default; a group naming a bare `dashscope` selects neither, which fails
 where it can be seen rather than sending the wrong shape.
 
+The request pins `parameters.result_format` to `"message"`. Text-generation
+returns whichever shape the MODEL defaults to otherwise — `output.text` for some,
+`output.choices[].message` for others — and a reader cannot be written against
+both. Pinning it makes the response shape a property of the request.
+
 Assertions check the payload rather than the status, because DashScope answers
 **200 with an error envelope**. They sit behind `{%- if not customer_display %}`
 so the published example stays clean.
@@ -36,3 +41,11 @@ so the published example stays clean.
 
 - `curl --fail-with-body`, so a non-2xx still prints the provider's message.
 - Greps the payload for `"choices"` rather than trusting the status.
+- **Amended in 0.2.5**: `parameters.result_format` is now pinned to `"message"`.
+  Without it DashScope's text-generation returns whichever shape the MODEL
+  defaults to — `output.text` for some, `output.choices[].message` for others —
+  so an example that reads `choices` failed on half the catalog with
+  `Cannot read properties of undefined`. Probed both ways on `qwen-flash`:
+  absent gives `{"output":{"text":…}}`, `"message"` gives
+  `{"output":{"choices":[…]}}`. The reader is unchanged; the request now asks for
+  the shape it reads.

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5}/src/unitysvc_data/examples/llm/dashscope-text-chat-shell/code-example-v1.sh.j2

@@ -6,7 +6,7 @@ set -e -o pipefail
 response=$(curl --fail-with-body -sS "{{ service_base_url }}" \
   -H "Content-Type: application/json" \
   -H "Authorization: Bearer ${UNITYSVC_API_KEY}" \
-  -d '{"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64}}')
+  -d '{"model": "{{ routing_key.model }}", "input": {"messages": [{"role": "user", "content": "Say this is a test"}]}, "parameters": {"max_tokens": 64, "result_format": "message"}}')
 
 echo "$response"
 {%- if not customer_display %}

{unitysvc_data-0.2.4 → unitysvc_data-0.2.5/src/unitysvc_data.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: unitysvc-data
-Version: 0.2.4
+Version: 0.2.5
 Summary: Standard examples and presets for UnitySVC data packages
 Author-email: Bo Peng <bo.peng@unitysvc.com>
 Maintainer-email: Bo Peng <bo.peng@unitysvc.com>