Initial cross-module actions - #227
Conversation
| name = "craft-basics" | ||
| module_hash = "d7edcb9150d12af76a54fbbac7b00b8bb24fab61bc1395b65da47547ad5d1b42" | ||
|
|
||
| [[classes]] |
There was a problem hiding this comment.
does this PR also add the ability to create pexe's without declaring a new class?
There was a problem hiding this comment.
That concept doesn't make any sense to me. Declaring new classes is what pexes are for!
There was a problem hiding this comment.
in PAC, agents negotiate a pexe on the fly which is "throwaway", its just meant to represent a swap of 2 objects
so all it has is
fn Swap(){
rekeyA()
rekeyB()
}
| # The pin is stamped by `pexe build`, which resolves the import among | ||
| # already-built archives (build craft-basics first). | ||
| [[imports]] | ||
| name = "craft-basics" |
There was a problem hiding this comment.
without a path to the code how is the code resolved? does it loop in the directory? curious why you went for this approach vs making the user specify the path
There was a problem hiding this comment.
ahh I see there is --deps so this is kind of like specifying a path but not at the pexe level
| .collect(); | ||
| entries.sort(); | ||
| thread_local! { | ||
| /// Per-thread module cache, keyed by validated manifest hash. |
There was a problem hiding this comment.
Does this get refreshed on new installs? ie when reload_catalog is called in driver
2 participants
Closes #113
Cross-module actions. Pexe plugins can now declare dependencies on other pexe plugins.
A dependency declaration has two parts: a module hash, and an alias. The alias is the name which is used locally to refer to the dependency - it is a purely local alias which is used in the Rhai script to refer to the dependency's classes/actions by name, and in the generated Podlang. Aliases must be locally unique (a plugin cannot use the same alias for two different imports) but does not need to be globally unique (two different plugins might use the same alias to refer to different dependencies, including different "versions" of the "same" plugin).
In the future we might want to introduce a package registry, which would give us globally unique names, and semantic version numbers for plugins. However, a content-based approach works for now.