we should store the motion source (and dependency lists) with sequences somehow #1
Description
currently, in the event of an upstream modification or invalidation, recompilation is needed. A way to facilitate this would be good; perhaps a fancier SEQUENCE operator that not only creates a sequence but also stores the workspace (and its dependencies, up to primitives) is in order. Close this when we have some kind of "build" or "rebuild" functionality for use after upgrades and the SEQUENCE operator (or its functional equivalent) stores the necessary data to support it. The build/rebuild (source-specification) system could also be used to distribute motion code between motion nodes, which all have (by design) different moteIDs for everything. Inserting the text of the motion code used to create a sequence into a comment in the implementation-language code stored in the database would work, but fails POLA as it would leak mote-IDs.
The counter-arguments, for "No, we shouldn't!" may be stronger -- since workspace creation is lightweight, the onus can be placed on the motion hacker who is creating a library for distribution to pay attention to what they're doing so that the library source may be presented as a single text block. Command line tools equivalent to a compiler, that invoke a target motion node, enter (or create) appropriate workspaces, and present motion code, could allow existing development practices to work with the Motion language using the same work flows as now exist with other compiled systems. Nobody expects a compiled C++ binary to yield its source code when properly prodded (unless it was compiled with the debug flag on, of course -- that's what this ticket is about, having a debug flag.)