Can a new user defined pkg encompass nothing more than references to previously defined pkgs?

[Don Green]

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?

[Ben Greenman]

Yes. You can make a new package whose main.rkt provides lots of
identifiers from other packages.

`#lang reprovide` is a nice way to get this done:

https://docs.racket-lang.org/reprovide/index.html

[Philip McGrath]

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 is not something that you refer to directly in your Racket programs. Instead, a package is a set of libraries that fit into the collection hierarchy, and you refer to libraries through their collection-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 library says that it is provided by the pict-lib package.If you’re reading this in a web browser, click pict/face 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

[Don Green]

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.

[Philip McGrath]

On Mon, Jun 7, 2021 at 1:46 PM Don Green <infodeve...@gmail.com> wrote:

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

This seems right, though I would say that the libraries will be your code.

 

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

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?

It is exceedingly unlikely that using `current-library-collection-links` is what you want. I would go so far as to say that you should not need to use any feature relating to collection links in normal use of Racket: those features are really for tinkering under the hood with new ways of building and installing Racket.

I'm going to try to offer some concrete advice, with a lot of assumptions—they may be wrong, but perhaps laying them out will highlight anything I've missed. Given that you've mentioned the path "/home/don/.plt-scheme/4.2.1/collects", it sounds like you have some code that predates Racket's package system. The right thing to do is to turn that code into a package and install it. (Note that, in Racket, making something a package doesn't mean publishing it. It may exist only as a directory on your local file system.)

Let's assume you have your code in paths like "/home/don/.plt-scheme/4.2.1/collects/tic-tac-toe" and "/home/don/.plt-scheme/4.2.1/collects/tetris". Make a new directory "/home/don/my-first-racket-package" and copy your code from "/home/don/.plt-scheme/4.2.1/collects" there. Create a file "/home/don/my-first-racket-package/info.rkt" with contents like this:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
#lang info

(define pkg-name "my-first-racket-package")
(define collection 'multi)
(define pkg-desc "My first Racket package")
(define version "0.0")
(define pkg-authors '(don))

(define deps
  '("base"))

(define build-deps
  '())
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At this point, you should have a directory structure like this:

• /home/don/my-first-racket-package/
• info.rkt
• tetris/
• … various files and directories …
  
• tic-tac-toe/
• … various files and directories …

An important caveat: for simplicity, I've assumed your code in "/home/don/.plt-scheme/4.2.1/collects" is not intermingled with the default collections of minimal Racket. If they are mixed up, copy only your files. (Corresponding collection directories will effectively be merged.)

Then, install your new package. You should not need to set any environment variables or change anything in "config.rktd": indeed, it would be best if you do not. You may want to uninstall and replace your system Racket installation to get a clean configuration. To install the package, run:

cd /home/don/my-first-racket-package/ && raco pkg install

If your code uses functionality outside of minimal Racket, you may get a warning about missing dependencies. Running:

raco setup --fix-pkg-deps my-first-racket-package

will attempt to add the necessary declarations to your "info.rkt" file.

In the future, you can run:

raco setup my-first-racket-package

to recompile all the code in your package. You can run these `raco setup` commands regardless of your current working directory.

I hope this helps!

-Philip