RFE: add pre-release script option when "Export portable tox"

[function-store]

So I am and have been using https://github.com/AlphaMoonbaseBerlin/TD_Private_Investigator for a long time to manage my component releases and it's wonderful. One of my favorite features is the ability to add a pre_release Text DAT that runs on release, so I can clean up my component --- rest parameters, set defaults, clean up my test scripts, lock my tox, release it to my R2 bucket, and the list goes on.

Since I've been using Embody more and doing some local releases using the "Export Portable tox" option I found myself needing this feature more and more!

[dylanroscover]

thanks @function-store — shipping in the next release: pre_release and post_release script hooks for export portable tox.

drop a text dat named pre_release as a direct child of the comp you're exporting: on export it runs on a throwaway staged copy (in /sys/quiet, same model as private investigator) — reset pars, set defaults, clean up test scripts freely; your live component is never touched. if the script errors — a deliberate raise on a failed sanity check, or just a bug — the export aborts and nothing ships; the staged copy is kept so you can inspect exactly what the hook did.

a text dat named post_release runs on your live original after the save — even if the save failed — and receives the success flag: upload to r2, notify, tag a release. private investigator's single pre-save hook can't do this half.

args[0] is the resolved save path in both hooks (post_release also gets args[1] = success), and me / parent() behave like pi, so existing pre_release scripts port over as-is. both hook dats are stripped from the exported .tox — your release pipeline (and any credentials in it) never ships to recipients. if you need hooks to run in place on the live comp instead, there's a hook_mode='live' escape hatch.

[function-store]

that is great!

a question --- if multiple releasable / tracked components are nested, is the release process recursively executed?

[dylanroscover]

good question — deliberately not recursive: hooks fire only for the component being exported, and a nested component's hooks neither run nor abort the parent's export (trust boundary — your export never executes an embedded third-party component's hook code). the artifact is handled recursively though: nested tracked components get their refs stripped all the way down, so the parent .tox ships fully portable.

but the workflow you're describing just shipped in v6.0.152 as ReleaseAll() (plus a release all pulse on the embody comp): one call exports every component that is both embody-tracked and hook-bearing as its own portable .tox, each through the full pipeline with its own hooks. tracked-and-hooked is the opt-in — deliberate, because third-party components arrive with their authors' pre_release DATs baked in (found a tauceti tweener in the wild carrying exactly that), and those should never batch-release by accident.

[chrsmlls333]

Does the export TOX process/action unsync all externalized DATs inside before saving the tox file, or would that be something I should do in pre_release?

[dylanroscover]

"export portable tox" automatically removes all externalizations out of the box, yeah. It's how embody gets released each version, from the dev project. pre_release is for anything beyond that, e.g. more advanced features. docs: https://dylanroscover.github.io/Embody/embody/externalization/?h=export+port#export-portable-tox

…

On Wed, Jul 29, 2026, 00:26 Chris Mills ***@***.***> wrote: *chrsmlls333* left a comment (dylanroscover/Embody#74) <#74 (comment)> Does the export TOX process/action unsync all externalized DATs inside before saving the tox file, or would that be something I should do in pre_release? — Reply to this email directly, view it on GitHub <#74?email_source=notifications&email_token=AAGDJUNYPRIJXSF7PJMJIDD5HESC7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJRGAZTENRQGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5110326017>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGDJUMAFIBS6SXQGE7ZINT5HESC7AVCNFSNUABFKJSXA33TNF2G64TZHM4DANZWHAYDMNZUHNEXG43VMU5TIOJVGQ3DCMRVG4ZKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAGDJUJ3RVDH75UUV7WCYWL5HESC7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJRGAZTENRQGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAGDJUOFRLLLP4GYLECUZMT5HESC7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJRGAZTENRQGE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[function-store]

"Once pre_release completes, post_release is guaranteed to run, even when the save itself failed."

I wonder if that is desirable especially thinking of uploading releases.

Furthermlre I often want to do a release for internal purposes but not yet upload to my bucket for example, so skipping post_release is something I'd want to do.

What do you think?

[dylanroscover]

so regarding your first point, it's already there, functionally speaking -- our docs just needed clarification. updated.
post_release receives the success flag as args[1], so the upload case could be:

# post_release
if not args[1]:
    return
upload(args[0])

internal vs public: i'd keep that as your policy rather than embody's. embody shouldn't learn what "internal" means for your component -- that's the road to skip_post, then skip_pre, then per-section selection. the pattern i'd reach for is a toggle on your own component:

# post_release
if not args[1] or not parent().par.Publish.eval():
    return
upload_to_r2(args[0])

one advantage over any flag i could add: it works from the manager ui export, where there's no python call to pass a flag into. one click before you export, visible in your component, saved with your project. a Releasechannel menu par (internal / public / beta) could cover more than two states the same way.

for suppressing hooks entirely there's already ExportPortableTox(run_hooks=False) -- skips both, ships the hook DATs as-is. embody's own self-updater uses it for its rollback backup.

if you'd rather drive this from the call than from a par, i can add a context pass-through -- ExportPortableTox(target=..., context={'publish': False}), forwarded to both hooks as an extra arg and settable once for a ReleaseAll batch. one generic channel, no release policy baked into embody. just lmk, happy to add it to a future release.