[racket-dev] PLaneT(2): Single vs multi-collection packages

On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
>
>> I am *very* strongly in favor of this -- I'd rather have
>> single-collection packages than multi-collection packages, if forced
>> to choose. I'm very glad that you and Laurent have done the work here.
>
> The main problem with this is that it brings in internal linking where
> code directly refers to other packages (implementations) and not
> modules (interfaces) as the default. This means we will see code like
> (require jays-awesome-data-structure) rather than (require
> data/awesome). I think this is bad because it makes it harder to deal
> with forking, maintainers abandoning their code, splitting packages
> into packages that just depend on 'jays-awesome-data-structure, rather
> than implementing it internally, etc. Obviously you can still deal
> with those things, but if the path of evolution we imagine starts off
> with single-package-with-package/collection-name-shared, then most
> packaged collections will have a package as their name.

First, I don't see why single-collection packages make things harder
to deal with re-implementing a package.  Imagine that I make
`disassemble` a single-collection package, and someone depends on it,
and then I abandon my code.  You can easily create a new package that
ships that collection.  I think that places the burden correctly --
it's easy to create packages initially, and handling abandoned
packages takes a little more work.  In JavaScript, where there's a
flat namespace, this works -- the Zepto library just provides the same
names as jQuery, even though they're different implementations and not
generic names.

Second, I think this is already happening.  Almost every package on
`pkg.racket-lang.org` provides a new collection which is the primary
code for the package, and which is named the same as the package.

Sam