On Sun, Jun 6, 2021 at 7:59 PM Ben Greenman <[email protected]> wrote:
> On 6/6/21, Don Green <[email protected]> wrote: > > > > Can a new user defined pkg encompass nothing more than references to > > previously defined pkgs so that every user created module references a > > single user defined pkg? > > Yes. You can make a new package whose main.rkt provides lots of > identifiers from other packages. I can see at least three different interpretations of the question. In an attempt to clear up any possible misunderstandings, let me try to pull them apart: 1. Ben's answer is correct if the question really meant, "so that every user created module references a single user defined" *module*. The omnibus module (`#lang reprovide` is a good choice) may be in the same package as other user-defined modules that use it, or additional packages may depend on the package containing the omnibus module. 2. If the question instead meant, "so that every user created" *package* "references a single user defined pkg", the answer is also yes, but in a different way. A good example of this would be the "typed-racket" package, which combines the packages "typed-racket-lib" and "typed-racket-doc". The "typed-racket" consists simply of an "info.rkt" file with appropriate definitions for `deps` and `implies`. 3. On the other hand, if the question literally meant, "so that every user created module references a single user defined pkg", then the answer, strictly speaking, is no, because modules can not refer to packages per se. The third possibility is where I see the most potential for misunderstanding. From Package Management in Racket", § 1.1 "What is a Package?" < https://docs.racket-lang.org/pkg/getting-started.html#%28part._.What_is_a_.Package_%29 >: > A package > <https://docs.racket-lang.org/pkg/Package_Concepts.html#%28tech._package%29> > is not something that you refer to directly in your Racket programs. > Instead, a package > <https://docs.racket-lang.org/pkg/Package_Concepts.html#%28tech._package%29> > is a set of libraries that fit into the collection > <https://docs.racket-lang.org/reference/collects.html#%28tech._collection%29> > hierarchy, and you refer to libraries through their collection > <https://docs.racket-lang.org/reference/collects.html#%28tech._collection%29>-based > paths. Libraries that are close in the hierarchy may be provided by > different packages, while a single package may provide libraries that are > far from each other in the hierarchy (but that are conceptually related, > somehow). > > Racket documentation tells you which package provides a given library. For > example, the documentation for the pict/face > <https://docs.racket-lang.org/pict/More_Pict_Constructors.html#%28mod-path._pict%2Fface%29> > library says that it is provided by the pict-lib package.If you’re > reading this in a web browser, click pict/face > <https://docs.racket-lang.org/pict/More_Pict_Constructors.html#%28mod-path._pict%2Fface%29> > to go straight to its documentation. > > Over time, packages may be refactored so that a library moves to a > different package, but the original package should continue to provide the > library, too, by declaring a dependency on the new package. More generally, > a package is intended to have an interface that only grows in terms of > libraries, bindings, and functionality, which provides a basic level of > backward compatibility. Incompatible changes should be implemented in a new > package. > -Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/01000179e4110586-44232b9f-4563-478e-b00a-6b909a341c13-000000%40email.amazonses.com.
