Scripts¶
A script is a Python file the team keeps on a project. It is not an IDE. You edit locally (or in the assistant’s editor), save a version on the project, and run that version against project data.
Scripts tab¶
Each project has a Scripts tab: name, description, latest version, last run status. From there you can:
- Upload a
.py(or save a version from the assistant) - Read version history (who, when, short message)
- Download a version
- Run with a small config form
- Open run history: status, duration, who started it, log, and links to datasets the run read or published
Viewers can inspect scripts and logs they can reach. Running or uploading needs a member (or higher) role on that project.
Local run vs saved script¶
Two complementary paths:
| Path | Use |
|---|---|
| Laptop / CI with the SDK | cs.connect(), compute, cs.publish(...). Optionally cs.track_script(__file__) so the published dataset remembers the file. |
| Project Scripts tab | The same kind of file, stored and runnable by teammates who never saw your laptop. |
cs.track_script() does not upload the script to the tab by itself. Saving on the project is a separate, explicit action.
Assistant-authored scripts¶
When the in-app assistant generates a script, it shows up in an editor you can change. Save as Script puts it on the project Scripts tab with provenance that it came from the assistant. Run executes the saved (or just-edited) code in CloudSprite’s script runner, not on whoever happened to have the browser open.
You still confirm anything that writes (publish, parameters, tags). A generated script is a draft until you save and run it.
What a good project script does¶
cs.set_org/cs.set_team/cs.set_project(or aClient(...)) so it cannot write to the last session’s project.- Filters with parameters (
cs.params.lot == "15"), not hard-coded dataset ids, unless the run config supplies them. - Publishes results into the same project.
- Does not embed API keys.