5 Packages🔗ℹ

description is a human-readable summary of the package’s purpose.

tags is a list of human-readable topics used for discovery.

url is the primary, or canonical URL used to guide a user towards more information (as opposed to secondary URLs that may appear in metadata).

provider is the name of the allegedly responsible distributor.

name is the name of the package.

edition, revision-number, and revision-names are the package’s edition, revision number, and revision names.

os-support is a list of possible values from (system-type 'os). If (system-type 'os) is not an element of os-support, then Denxi will not install the package.

racket-versions is a list of Racket version ranges that should be interpreted as a set of supported Racket versions. If (version) is not an element of any version interval, then assume that the software created with build will not function with the running version of Racket.

metadata is a hash table of user-defined metadata. In the event entries of this table appear redundant with other structure fields, prefer the values in the structure fields.

inputs is a list of package inputs.

outputs is a list of defined package outputs.

A function that maps output names to subprograms in outputs is surjective, but might not be injective. Denxi does not distinguish the two, meaning that non-injective lookups will create redundant data on disk (Denxi assumes that different output names imply different file distributions). When non-surjective, then an output’s subprogram might be inaccessible. This can happen if a package instance is manually created with faulty data. Bijective lookups do not have these problems, and they are easy to make using denxi/pkgdef.

If link-path is #f, then the name of the symbolic link will match the name of the package.

If output-name is #f, then install will use DEFAULT_STRING.

The subprogram is not atomic, so failure may result in a broken intermediate state on disk. This procedure should be used in the context of a transaction to avoid this problem.

All install messages are instances of $package.

This procedure defaults to the identity function, so no code is replaced. The procedure may instead return a subprogram if it intends to add to a subprogram log.

This procedure is useful for standardizing definitions, or for analyzing builds. Define with care. This procedure may override all package definitions, which can render a Denxi process inoperable or unsafe.

Take for example a function that returns the same static package definition, which has one dependency.

(current-package-definition-editor (lambda (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 Denxi 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 (current-package-definition-editor).

This procedure defaults to the identity function, so the package is used as-is.

This parameter would likely be easier to use in a launcher, since struct bindings are available to operate on the actual package.

When used as the current-package-editor, Denxi is forced into an extreme interpretation of side-by-side (SxS) installations.

In this mode, package conflicts become vanishingly improbable. The cost is that Denxi’s cycle detection and caching mechanisms are defeated because they will never encounter the same package enough times for them to matter. Installations using sxs consume more resources, and are vulnerable to non-termination. Stop using sxs the moment you don’t need it.

sxs is useful for handling unwanted package conflicts. Re-running a single installation using sxs will force installation of conflicting packages without disturbing other installed packages.

Note that the package inputs are still subject to caching. Only the output directories that would hold links to inputs are not cached.

5.1 Package Settings🔗ℹ

Each list in DENXI_INSTALL_SOURCES consists of three strings:

1. The path to a symbolic link to create with respect to (current-directory).

2. The name of a desired output from a package definition.

3. A URL, file path, or launcher-specific string used to find the package definition.

Each element is in the form (cons pattern input-expr). The input of name input-name is replaced with the (evaluated) input-expr for all package queries matching pattern.

If pattern is a string, then it is used as an argument to pregexp before matching. If pattern is a symbol, then it is first coerced to a string and then used as an argument to pregexp.

1. The path of a symbolic link to create with respect to (current-directory).

2. A URL, file path, or launcher-specific string used to find the package definition.

The output is assumed to be "default".

5.2 Package Messages🔗ℹ