Following from Philip's 3rd point, which I think is very relevant, I surmise that I really should: 1) build libraries ;that reference my code (These libraries are built within a user-defined package.) 2) Then my initial question, refined, becomes: Can a new user defined library encompass nothing more than references to previous user defined libraries? (I think the answer is: yes). 3) Since the library is said to be referenced through their collection-based paths this leads me to wonder: Am I expected to create my own pathed-collection that gives my code independence from the default installled racket pathed-collections?
Then am I to use: (current-library-collection-links paths) to link my collection into the racket system? I would then expect (current-library-collection-paths) to return the 2 default racket v. 8.1 collection-paths, and my own collection-path. On Sunday, June 6, 2021 at 7:23:15 PM UTC-6 Philip McGrath wrote: > 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/02264bb7-27c0-4f79-9ad4-75626c3b4b7an%40googlegroups.com.
