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 <benjamin...@gmail.com> wrote: > >> On 6/6/21, Don Green <infodeve...@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/02264bb7-27c0-4f79-9ad4-75626c3b4b7an%40googlegroups.com.
