Proposal: Reserved module namespace for packages on Hackage

[David Menendez]

On Mon, Aug 18, 2008 at 8:03 PM, Isaac Dupree <isaacdupree at charter.net> wrote:
> David Menendez wrote:
>>
>> Implementation costs are minor.
>
> There is a serious cost: Sometimes another package is *supposed to* provide
> the same interface, including the same module names (e.g. forks or
> reimplementations.  e.g. SOE). If Hackage rejected them, we would have a
> serious problem once people started depending on any package using a Lib.
> name.

Would we? How many packages out there are drop-in replacements? Even
things like Data.List.Stream, which is a drop-in replacement for
Data.List, uses a different module name. The packages I've seen that
abstract over other packages tend to use preprocessor commands to get
the right modules.

I can see your point about forks. That's one case where it might be
better to use the same module names as a different package. But I'm
leery of relying on two modules with the same name having the same
interface.

The ideal solution would be something like the package mounting
proposal, but that has a major implementation cost. This is more of a
stop-gap measure that could be implemented today.

<http://hackage.haskell.org/trac/ghc/wiki/PackageMounting>

> But it's not hard to pretty much avoid conflicts; you don't even need the
> Lib. prefix, you can just use the package name as your top-level module
> name. (right? or does hackage arbitrarily reject some module names?)

As I understand it, Hackage complains if you use a top-level name that
isn't on the approved list. Putting the package name at the top-level
is also a possibility, but putting it one level down is more
future-proof.

Really, all my proposal needs is to add "Lib" to the list of
acceptable top-level names, and to have some document on the web
explain what it's for.

-- 
Dave Menendez <dave at zednenem.com>
<http://www.eyrie.org/~zednenem/>