On Sun, Jun 6, 2021 at 7:59 PM Ben Greenman <benjaminlgreen...@gmail.com> wrote:
> On 6/6/21, Don Green <infodeveloper...@gmail.com> 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 racket-users+unsubscr...@googlegroups.com. 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.
