[karhu]

A release in a remote registry outlives the machine that built it, so its manifest must name the exact code. A remote or S3 registry now accepts only a release whose manifest records TimeNet code without local changes. A local registry accepts any release. There is no override.

The check reads build_env.git in the manifest, not the installed code, because a publish copies a release that was built earlier. PackageSnapshot and TimeNetSnapshot get require_no_local_changes(), and WritableRegistry gets the property requires_committed_code (False only for LocalRegistry) and the method require_committed_code(manifest).

Every way to publish checks the rule:

• put_release() refuses before it uploads anything. put_dataset() publishes through put_release(), so it refuses too.
• copy_release() checks every release that it copies before it copies anything, so timenet.publish() and timenet-build build --publish-to leave the destination unchanged.

The error names the registry, the release and the package with local changes. It says to build the release again from committed code, or to keep it in a local registry. With --publish-to, a build with local changes still lands in the local registry, and only the publish step fails.

The docs describe the rule in a new section, "Committed code for remote registries".

This replaces the first design of this PR, which gated publish_pipeline() on a snapshot of the installed code. Main removed publish_pipeline(): a build now always lands in the local registry, and a publish is a separate copy.

Closes TNET-165

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[github-actions]

✅ CI checks passed

Check	Status
Quick checks	✅ Passed
Tests (Python 3.13)	✅ Passed
Tests (Python 3.11)	✅ Passed

_{Updated for f74087e · run #8369}

[karhu]

@RealLast Same here, addressed your feedback. Please take another look!

[RealLast]

Thanks! Minor nits for clean up