[racket-dev] new package system collections and conflicts

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Sun Nov 30 10:22:49 EST 2014

Given the example from the documentation, of the `tic-tac-toe` package 
and "conflicts" (quoted at end of this email), instead, why isn't the 
norm to do:

     (require tic-tac-toe)

Or, when necessary:

     (require tic-tac-toe/matrix)

Why, when one installs a package named `tic-tac-toe`, would one be 
referencing modules of the package as `data/matrix`?

I don't recall ever seeing a situation in which I wanted different 
third-party Racket packages to be stomping over each other's 
module-naming namespaces.

For people who want to release lots of well-behaved reusable packages, 
using good practices, with minimal effort and head-scratching, things 
like this are a problem.

> 2 Package Concepts
>
> A package is a set of modules in some number of collections. Modules 
> installed using the Racket package manager are required like any other 
> modules. For example, if the package tic-tac-toe contains the module 
> "matrix.rkt" in a "data" collection, then after tic-tac-toe is installed,
>
>     (require data/matrix)
[...]
> 2.5 Package Conflicts
>
> Two packages are in conflict if they contain the same module. For 
> example, if the package tic-tac-toe contains the module file 
> "data/matrix.rkt" and the package factory-optimize contains the module 
> file "data/matrix.rkt", then tic-tac-toe and factory-optimize are in 
> conflict.
>
> A package may also be in conflict with Racket itself, if it contains a 
> module file that is part of the base Racket implementation. For 
> example, any package that contains "racket/list.rkt" is in conflict 
> with Racket.
>
> For the purposes of conflicts, a module is a file that ends in ".rkt", 
> ".ss", or ".scrbl".

Neil V.


Posted on the dev mailing list.