[racket-dev] new package system collections and conflicts

We should change that example. It would indeed be strange for package
named "tic-tac-toe" would introduce a `data/matrix` module, and the
documentation really shouldn't suggest that it makes sense for a
package to introduce overlaps that are not reasonably expected from the
package name.


There are plenty of real examples where it's sensible for different
packages to introduce modules in overlapping collections, though.
Sometimes, it's because different packages implement different facets
of a conceptual whole, such as "math-lib", "math-doc", and "math-test"
all extending the "math" collection. Sometimes, it's more a mater of
history, such as "compatibility-lib" extending several different
collections. And then there are example that you might classify as
either of those or as a third kind, depending on how you look at it:
"draw-lib" adds `racket/draw`, and "gui-package-manager" adds
`pkg/gui`.


The "data" collection is among those that were intended to be extended
by multiple packages. Whether that's really a good idea remains to be
seen, but that's why "data" shows up as an example in the manual.
(Again, though, no one would expect a "tic-tac-toe" package to
introduce a new module in "data".)


At Sun, 30 Nov 2014 10:22:49 -0500, Neil Van Dyke wrote:
> 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.
> 
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev