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: (1) I don't want to publish package A, because I doubt anyone will find it useful. 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 itself. (2) 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. (3) 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 same:

CREATE TABLE nameables ( -- an ancestor table name varchar NOT NULL DEFAULT '<name not given>' , description varchar NULL , comments varchar NULL ) TABLESPACE tabsp_pcltcatalogs; GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE nameables TO 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? Regards, Andrey -- 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.