10 Future Plans

10.1 Short Term

This section lists some short term plans for the package manager. These are important, but didn’t block its release. The package manager will be considered out of beta when these are completed.

• The official catalog server will divide packages into three categories: ring-0, ring-1, and ring-2. The definitions for these categories are:

  • ring-2 — No restrictions.

  • ring-1 — Must not conflict any package in ring-1 or ring-0.

  • ring-0 — Must not conflict any package in ring-1 or ring-0. Must have documentation and tests. The author must be responsive about fixing regressions against changes in Racket, etc.

  These categories will be curated by PLT.

  Our goal is for all packages to be in ring-1, with ring-2 as a temporary place while the curators work with the authors of conflicting packages to determine how modules should be renamed for unity.

  However, before curation is complete, each package will be automatically placed in ring-2 or ring-1 depending on its conflicts, with preference being given to older packages. (For example, if a new package B conflicts with an old package A, then A will be in ring-1, but B will be in ring-2.) During curation, however, it is not necessarily the case that older packages have preference. (For example, tic-tac-toe should probably not provide "data/matrix.rkt", but that could be spun off into another package used by both tic-tac-toe and factory-optimize.)

  In contrast, the ring-0 category will be a special category that authors may apply for. Admission requires a code audit and implies a "stamp of approval" from PLT. In the future, packages in this category will have more benefits, such as automatic regression testing on DrDr, testing during releases, provided binaries, and advertisement during installation.

  The PLaneT compatibility packages will also be included in the ring-1 category, automatically.

• In order to mitigate the costs of external linking vis a vis the inability to understand code in isolation, we will create exception printers that search for providers of modules on the configured package catalogs. For example, if a module requires "data/matrix.rkt", and it is not available, then the catalog will be consulted to discover what packages provide it. Only packages in ring-1 or ring-0 will be returned. (This category restriction ensures that the package to install is unique.)

  Users can configure their systems to then automatically install the package provided is has the appropriate category (i.e., some users may wish to automatically install ring-0 packages but not ring-1 packages, while others may not want to install any.)

  This feature will be generalized across all package catalogs, so users could maintain their own category definitions with different policies.

10.2 Long Term

This section lists some long term plans for the package manager. Many of these require a lot of cross-Racket integration.

• The official catalog server is bare bones. It could conceivably do a lot more: keep track of more statistics, enable "social" interactions about packages, link to documentation, problem reports, licenses, etc. Some of this is easy and obvious, but the community’s needs are unclear.

• It would be nice to encrypt information from the official package catalog with a public key shipped with Racket, and allow other catalogs to implement a similar security scheme.

• Packages in the ring-0 category should be tested on DrDr. This would require a way to communicate information about how they should be run to DrDr. This is currently done via the "meta/props" script for things in the core. We should generalize this script to a "meta/props.d" directory so that packages can install DrDr metadata to it.

• We hope that this package system will encourage more incremental improvements to pieces of Racket. In particular, it would be wonderful to have a very thorough "data" collection of different data-structures. However, our existing setup for Scribble would force each new data structue to have a different top-level documentation manual, rather than extending the documentation of the existing "data" collection. Similar issues will exist for the "net" and "file" collections. We should design a way to have such "documentation plugins" in Scribble and support similar "plugin" systems elsewhere in the code-base.

• The user interface could be improved, including integration with DrRacket and a GUI. For example, it would be good if DrRacket would poll for package updates periodically and if when it was first started it would display available, popular packages.