[Haskell-cafe] HackageDB is not for ... ?

Andrey Sisoyev Andrejs.Sisojevs at nextmail.ru
Mon Jan 4 20:26:30 EST 2010

Hello everybody!

I'm planning not a small project, and intuition suggests me, that I should
use heavily the rule "separate and rule". So I must separate the project
into many maximum independent and general pieces (packages), make them, and
finally glue it into my project. The pieces and their dependencies will form
an oriented graph without cycles and with overall path finishing into the
final project.
So far so good I have made two pieces: 
** http://hackage.haskell.org/package/PCLT-DB
** http://hackage.haskell.org/package/PriorityChansConverger

But I'm coming to understand, that it's not polite to other community
members to publish just every package my project will consist of, because we
do not want to garbage HackageDB. 
Consider cases:
I don't want to publish package A, because I doubt anyone will find it
But I develop independent packages B and C, that will be usefull for the
community, and want to publish them on Hackage, but they require package A!

[Solution] Publish package A, but make it maximum general and complete in

I don't want to publish package A, because it's tiny. Well imagine something
same popular and useful, like Ord class. 10 lines of code. But I don't want
to repeat these lines in every other package.

[Solution] Same as for (1) I guess.

I don't want to publish package A, because it's about adjacent system.
I'm making 3 packages, that all use DBMS (PostgreSQL). All three are thught
to be independent. But! They all in their DDL scripts use table inheritance
from a common ancestor table "nameables", which is everywhere defined the

> CREATE TABLE nameables ( -- an ancestor table
>          name        varchar NOT NULL DEFAULT '<name not given>'
>        , description varchar     NULL 
>        , comments  varchar     NULL
> ) TABLESPACE tabsp_pcltcatalogs;
> user_someCurrentSchema_data_admin;
> GRANT SELECT ON TABLE nameables TO user_someCurrentSchema_data_reader;

Now what do I do with that??  
The problem gets even more complicated be the fact, that dependent packages
may use different DB schemes, so DDL sql script from Nameables will have to
be run additionally for them. But that's easy to solve - just decide,
whether to add or not by build-depends a comment "-- with DDL init", and
maybe additional instruction in README.

[Solution] ???
[Solution A] Well, of course, I can pretend that this package may be is
Haskellish enough, by inventing something which I don't really need:

> data Name = Name { nName :: String, nDescription :: Maybe String,
> nComments :: Maybe String }
> class Nameables a where
> getName :: a -> Name
> class HasPrimaryKey a => NameableInDBOnly a where
> getNameFromDB :: Connection -> a -> IO Name

This + sql script and instruction, how to initialize DB. Is it okay to
publish this? Looks like garbage...

[Solution B] Do my own version control and add same pieces to every package
that use Nameable. Don't like this solution. May be I should start using
other repository systems like github or darcs, and then this solution will
seem more natural to me?.. 
These are my thoughts on the theme. In any case I come to wanting to publish
the packages anyway. Probably I miss something in ideology and methodology
of using Hackage as community repository.

And what do you think about it?

View this message in context: http://old.nabble.com/HackageDB-is-not-for-...---tp27022312p27022312.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

More information about the Haskell-Cafe mailing list