|(require xiden/plugin)||package: xiden|
A plugin is a Racket module defined by a user. Plugins extend Xiden where it would otherwise have limited behavior. A plugin runs directly in Xiden’s runtime, with the same level of privilege as the OS-level user. This means that a plugin may freely reconfigure Xiden, if not outright harm a system.
Xiden applies load-from-plugin internally to get references to user-defined extensions. The bindings defined below are not provided by Xiden, but are instead provided by a plugin to support the written behavior.
Defaults to default-catalog.
When a user uses a plain string where a source is expected, then Xiden uses coerce-source to convert it to a source. By defining this, you control how strings map to byte sources.
(define (string->source s) (first-available-source (list (file-source s) (http-source s)) null))
Used by xiden/archive when it cannot extract files from path on its own.
This procedure defaults to the identity function, which means no code is replaced. Otherwise, you may return an alternative definition to override original.
This procedure is useful for standardizing definitions, or for analyzing builds in a workspace. Define with care. This procedure can override every package definition, which can render a Xiden process inoperable or unsafe.
Take for example a function that returns the same static package definition, which has one dependency.
(define (before-new-package original) (struct-copy bare-racket-module original [code '((input "pkgdef" (sources "https://example.com/other.rkt")) (output "default" pkgdef-input := (input-ref "pkgdef") pkgdef-path := (resolve-input "pkgdef") (install #f #f pkgdef-path)))]))
This creates builds that will not terminate. Even if Xiden downloads a new package definition from "https://example.com/other.rkt", it will only be replaced by another instance of the same data returned from before-new-package.