4 Package Metadata

Package metadata, including dependencies on other packages, is reported by an "info.rkt" module within the package. This module must be implemented in the info language.

For example, a basic "info.rkt" file might be

#lang info

(define version "1.0")

(define deps (list _package-source-string ...))

The following "info.rkt" fields are used by the package manager:

• collection — either 'multi to implement a multi-collection package or a string or 'use-pkg-name to implement a single-collection package. If collection is defined as a string, then the string is used as the name of the collection implemented by the package. If collection is defined as 'use-pkg-name, then the package name is used as the package’s collection name.

  Beware that omitting collection or defining it as 'use-pkg-name means that a package’s content effectively changes with the package’s name. A package’s content should normally be independent of the package’s name, and so defining collection to a string is preferable for a single-collection package.

• version — a version string. The default version of a package is "0.0".

• deps — a list of dependencies, where each dependency has one of the following forms:

  • A string for a package source.

  • A list of the form

    (list package-source-string

    keyword-and-spec ...)

    where each keyword-and-spec has a distinct keyword in the form

    keyword-and-spec		=		'#:version version-string
    		|		'#:platform platform-spec
    platform-spec		=		string
    		|		symbol
    		|		regexp

    A version-string specifies a lower bound on an acceptable version of the needed package.

    A platform-spec indicates that the dependency applies only for platforms with a matching result from (system-type) when platforms-spec is a symbol or (path->string (system-library-subpath #f)) when platform-spec is a string or regular expression. See also matching-platform?. For example, platform-specific binaries can be placed into their own packages, with one separate package and one dependency for each supported platform.

  • A list of the form

    (list package-source-string version-string)

    which is deprecated and equivalent to

    (list package-source-string '#:version version-string)

  Each element of the deps list determines a dependency on the package whose name is inferred from the package source (i.e., dependencies are on package names, not package sources), while the package source indicates where to get the package if needed to satisfy the dependency.

  Using the package name "racket" specifies a dependency on the Racket run-time system, which is potentially useful when a version is included in the dependency. For most purposes, it’s better to specify a versioned dependency on "base", instead.

• build-deps — like deps, but for dependencies that can be dropped in a binary package, which does not include sources; see Source, Binary, and Built Packages. The build-deps and deps lists are appended, while raco pkg create strips away build-deps when converting a package for --binary mode.

• implies — a list of strings and 'core. Each string refers to a package listed in the deps and indicates that a dependency on the current package counts as a dependency on the named package; for example, the gui package is defined to ensure access to all of the libraries provided by gui-lib, so the "info.rkt" file of gui lists "gui-lib" in implies. Packages listed in implies list are treated specially by updating: implied packages are automatically updated whenever the implying package is updated. The special value 'core is intended for use by an appropriate base package to declare it as the representative of core Racket libraries.

• setup-collects — a list of path strings and/or lists of path strings, which are used as collection names to set up via raco setup after the package is installed, or 'all to indicate that all collections need to be setup. By default, only collections included in the package are set up (plus collections for global documentation indexes and links).