Conversation
Adds the standalone Python SDK (import: b2c_tooling_sdk; dist: salesforce-b2c-tooling-sdk) that mirrors the TypeScript b2c-tooling-sdk public surface and interoperates with the B2C CLI (shared auth-session store and config files). Includes auth (all methods), config resolution, OCAPI/SCAPI typed clients, WebDAV, operations, SLAS shopper tokens, a sync facade, docs, and runnable example notebooks. Also adds python/LICENSE (Apache-2.0), python/.gitignore, and a tag-triggered GitHub Actions release workflow (python-v*) that builds the wheel/sdist and attaches them to a GitHub Release for pip installation.
Document installation via git+https from the python branch (and pinned tags) as a temporary arrangement during development, until the package is published to PyPI. Remove the now-unneeded GitHub Release workflow — the git+https install builds straight from the ref and needs no release assets.
Interactive script proposes the next minor version, runs the quality gate, bumps pyproject.toml, commits, tags python-v<version>, and pushes to the fork after confirmation. RELEASE.md now leads with the script; manual steps kept as reference.
get_default_data_dir() now mirrors @oclif/core's Config.dataDir (and the sibling get_b2c_config_directory): $B2C_DATA_DIR | $XDG_DATA_HOME | (win32 %LOCALAPPDATA%) | ~/.local/share, then /b2c. Previously it returned ~/Library/Application Support/@salesforce/b2c-cli on macOS, so find_auth_session could never locate sessions written by the b2c CLI. The identical bug still exists in the TS SDK (session-store.ts getDefaultDataDir).
Five auth/API scenarios (oauth_ocapi, oauth_scapi, basic_webdav, cli_session, slas_shopper) in async + sync, plus matching notebooks, all reading one git-ignored dw.json (dw.example.json is the pseudo-value template).
…irectly The sync facade proxies the whole object graph, so instance.webdav from b2c_tooling_sdk.sync.resolve_config is already blocking. The sample was await-ing webdav.put/get/delete, which raised TypeError on a None result. Call the WebDAV methods directly (no asyncio) and correct the docstring + README note that repeated the wrong 'wrap in asyncio.run' premise.
Adds browser_login_{async,sync}.py + notebook/06-browser-login.ipynb showing
the SDK equivalent of 'b2c auth login <clientId>': create_user_auth_strategy +
get_token_response runs the Authorization Code + PKCE browser flow and persists
the session to the shared auth-sessions store (reusable by the CLI).
Adds multi_env_{async,sync}.py + notebook/07-multi-env.ipynb + a bundled
multi-env.example.json demonstrating named-environment selection from a
multi-config dw.json via ResolveConfigOptions(instance=...). Offline; no
credentials or network required.
… deterministic Read specs from the sibling JS package (packages/b2c-tooling-sdk/specs) instead of vendoring a second copy under python/specs, and stop bundling specs in the wheel/sdist. Generate models with datamodel-code-generator's builtin formatter, then format each file with the project's pinned ruff -- datamodel's black/isort integration silently no-ops on recent toolchains, which made regeneration non-deterministic. Pin datamodel-code-generator so output stays stable. Regenerated models are AST-identical (pure reformat).
…s, and content Add live Jupyter notebooks demonstrating the admin Data APIs with OAuth client-credentials, parsing responses into the SDK's generated Pydantic types: - 10-scapi-catalogs: list catalogs via create_catalogs_backend and a typed product/catalogs/v1 call (SCAPI Data) - 11-ocapi-products: product search + product by id (OCAPI Data) - 12-ocapi-content-assets: list a folder's content + content asset by id (OCAPI Data) SCAPI Admin covers only catalog listing here, so products/content go through the OCAPI Data API; notebooks handle the OCAPI Data allow-list 403 gracefully. Also add the previously-uncommitted SLAS Shopper notebooks (08/09) and document all of them in the samples README.
Add python/CLAUDE.md documenting the Python SDK subproject (commands, architecture, async/sync facade, generated models, conventions), and a using-b2c-tooling-sdk skill guiding consumption of the SDK from scripts and notebooks (install, auth by use case, available clients and operations).
…ing SDK Move the using-b2c-tooling-sdk consumer skill out of the Python package's local .claude/skills into a first-class, installable skills plugin so it ships to consumers. Register it in plugins.json (release packaging), both marketplace manifests, and the CLI skill installer (sources.ts + SkillSet type) so it installs via the plugin marketplace or 'b2c setup skills b2c-python-sdk'. Add the missing references/api-catalog.md the skill points to.
Move the Python package (src, tests, docs, scripts, build/config) from python/ into python/b2c-tooling-sdk/, alongside the sibling python/samples/. Pure relocation.
The Python SDK is headed for SalesforceCommerceCloud/b2c-developer-tooling@main, so update the git-install URL, release badge, and 'python' branch prose in the SDK README, docs/index, and the b2c-python-sdk skill to reference the upstream repo and main branch. Also fix the skill's SDK-development pointer to python/b2c-tooling-sdk/CLAUDE.md after the reorg. RELEASE.md is left untouched — it documents the current fork-based release process. Note: the @main install command only works once the branch is merged upstream.
Remove unused imports, sort imports, and apply ruff format to the offline docs/notebooks so the SDK lint/format gate is green. Autofix only; no behavioral changes. Samples notebooks are left untouched.
…tory The SDK moved into python/b2c-tooling-sdk/; update the samples requirements pin to the new subdirectory path.
Point the samples requirements at SalesforceCommerceCloud/...@main instead of the priandsf fork, matching the consumer install docs. Release machinery (RELEASE.md, release.sh) still targets the fork by design.
The b2c-python-sdk skill set was added to SKILL_SOURCES but the ALL_SKILL_SETS test still expected 5 entries. Include it and bump the expected length to 6.
Collaborator
|
I did a review and there were some good findings but not critical. However we're declaring python 3.10 support here but that's failing the tests. 3.11+ works. I'd suggest just dropping 3.10 instead of resolving it. But we should probably add a CI step to run pytest, ruff, etc. Basic coverage. We can even scope that to run only on PRs with python/* file changes (skipping otherwise). That might be good to add now so future PRs have a baseline regression suite for py For reference these are some of the issues identified but all this looks like eventual followups or nit-picking rather than necessary here (except for the CI stuff):
|
Collaborator
|
Also I highly recommend we get this onboarded into changesets here. all packages use it even if they aren't nodejs (for instance the agent-skills and docs site here are in changesets). https://github.com/changesets/changesets/blob/main/docs/versioning-apps.md |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@W-24132874@
What
Adds a Python port of the B2C tooling SDK under
python/b2c-tooling-sdk/, plus supporting samples, documentation, and an agent-skills plugin for consuming it. This is additive — it lives entirely underpython/and does not touch the existing TypeScript packages.Highlights
salesforce-b2c-tooling-sdk(importb2c_tooling_sdk) — a faithful port of@salesforce/b2c-tooling-sdk: async-first with a complete synchronous facade (b2c_tooling_sdk.sync), Python 3.10+.dw.json,~/.mobify,settings.json, multi-env aliases).ClientResult, never raise on 4xx/5xx) and higher-level success-or-raise operations (code deploy, jobs, sites, catalogs, BM users/roles, sandboxes, metrics, logs).auth-sessions.jsonand config files as@salesforce/b2c-cli, so a session created byb2c auth loginworks from Python and vice versa.python/samples/) — runnable scripts and Jupyter notebooks for each scenario; offline, mocked, CI-safe notebooks under the SDK'sdocs/notebooks/.b2c-python-sdkagent-skills plugin — a consumer skill (using-b2c-tooling-sdk) with a full symbol catalog, wired into the marketplace and theb2c setup skillsinstaller.Notes for reviewers
SalesforceCommerceCloud/…@mainand only resolve once this merges tomain(chicken-and-egg by design; PyPI publishing is future work).RELEASE.md/release.shintentionally still describe the interim fork-based tag release process.