7 Future Plans

7.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 PNR will divide packages into three categories: planet, solar-system, and galaxy. The definitions for these categories are:

  • galaxy — No restrictions.

  • solar-system — Must not conflict any package in solar-system or planet.

  • planet — Must not conflict any package in solar-system or planet. 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 the solar-system, with the galaxy 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 galaxy or solar-system 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 solar-system, but B will be in galaxy.) 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 planet 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 solar-system category, automatically.

• In order to mitigate the costs of external linking vis a vis the inability to understand code in isolation, we will create a module resolver that searches for providers of modules on the configured package name resolvers. For example, if a module requires "data/matrix.rkt", and it is not available, then the PNR will be consulted to discover what packages provide it. Only packages in solar-system or planet 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 planet packages but not solar-system packages, while others may not want to install any.)

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

7.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 PNR 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 name resolver with a public key shipped with Racket, and allow other resolvers to implement a similar security scheme.

• Packages in the planet 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.

• Packages can contain any kinds of files, including bytecode and documentation, which would reduce the time required to install a package (since we must run raco setup). However, packages with these included are painful to maintain and unreliable given users with different versions of Racket installed.

  One solution is to have a separate place where such "binary" packages are available. For example, PLT could run a PNR for every Racket version, i.e., "https://binaries.racket-lang.org/5.3.1.4", that would contain the binaries for all the packages in the planet category. Thus, when you install package tic-tac-toe you could also install the binary version from the appropriate PNR.

  There are obvious problems with this... it could be expensive for PLT in terms of space and time... Racket compilation is not necessarily deterministic or platform-independent.

  This problem requires more thought.

• 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.

• The core distribution should be split apart into many more packages. For example, Redex, Plot, the Web Server, and the teaching languages are natural candidates for being broken off.

• The core should be able to be distributed with packages that will be installed as soon as the system is installed. Ideally, this would be customizable by instructors so they could share small distributions with just the right packages for their class.