3 Packages
| (require xiden/package) | package: xiden |
struct
(struct package ( description tags url provider name edition revision-number revision-names os-support racket-versions metadata inputs output-names build)) description : string? tags : (listof non-empty-string?) url : url-string? provider : non-empty-string? name : non-empty-string? edition : non-empty-string? revision-number : revision-number? revision-names : (listof non-empty-string?) os-support : (listof symbol?) racket-versions : (listof (list/c non-empty-string?)) metadata : (hash/c symbol? string?) inputs : (listof input-info?) output-names : (listof non-empty-string?) build : (-> non-empty-string? (logged/c void?))
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 either calls to build will fail, or the software created with build will not function.
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.
output-names is a list of defined package outputs.
build procedures created using xiden/pkgdef are always surjective, but might not be injective.
Xiden will not verify if build procedures are bijective. If build is not bijective, then build’s relationship with the host system varies slightly. If build is not injective, then it may create redundant data on disk because Xiden assumes that different output names imply different file distributions. If build is not surjective, then a logged procedure might be inaccessible. This can happen if a package instance is manually created with faulty data. Bijective build procedures do not have these problems.
value
value
Returns a logged procedure that always fails and adds $package:output:undefined to the program log.
procedure
(install link-path output-name package-definition-variant) → logged? link-path : (or/c #f path-string?) output-name : (or/c #f string?) package-definition-variant : any/c
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 logged procedure 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.
3.1 Package Messages
struct
(struct $package:log $package (query output-name messages) #:prefab) query : package-query? output-name : string? messages : messy-log/c
struct
(struct $package:output $package () #:prefab)
struct
(struct $package:output:built $package:output () #:prefab)
struct
(struct $package:output:reused $package:output () #:prefab)
struct
(struct $package:output:undefined $package:output () #:prefab)
struct
(struct $package:unsupported-racket-version $package (versions) #:prefab) versions : racket-version-ranges/c
struct
(struct $package:unsupported-os $package (supported) #:prefab) supported : (listof symbol?)
struct
(struct $package:unavailable-output $package (available) #:prefab) available : (listof string?)