yesodweb/persistent — comment on commit 41f3a00cc554185b1a7ce0e95a32b40e1c297ba2
File:  line 0
By gregwebs:

I don't care about how long it takes to compile things. All I care about is
that they correctly compile. I know people do complain about compilation
speed, but it is often related to them either having to had blow away their
.cabal because of a broken install, use cabal-dev to avoid broken installs,
or that cabal is re-compiling packages.

So I think the only (but very important) reason to not have separate
packages for the user is to avoid dependency complications. For us it is to
avoid extra hassle when developing.

I don't think we have to worry about dependency hell here. If we do, we
could have a persistent package that depends on persistent-store &
persistent-query, and have users reference that. I also don't see this
either as making extra hassle for us. We have all the tools in place to
deal with multiple packages - I think all of the multiple package hassle
for us still comes down to dependency issues.

I know that people aren't making backends because they can't implement the
*query* interface. My hope is that users will start making Persistent
*store* backends for every database imaginable. Obviously we can't know
what helps or impedes them after this split until it first occurs. The only
thing we know for certain is they won't want the enumerator dependency and
the query code as baggage. How much of an issue that amounts to is of
course unknown.

Back to my previous idea:

persistent/persistent-store
persistent/persistent-query
persistent/persistent/store -> ../persistent-store
persistent/persistent/query -> ../persistent-query

persistent/persistent.cabal: hs-source-dirs: store, query

We can keep the persistent package as a monolith but still release a
persistent-store sans the enumerator dependency. We don't have to release
the persistent-store package right now- we can wait until someone complains
about the enumerator dependency and then do it. There would be little
point in releasing a persistent-query package, so we could keep the query
code in persistent rather than symlinking with a persistent-query
directory.

So if you really want to do the monolith lets definitely keep the store and
query code partitioned at least with directories somehow, and be ready to
make a persistent-store release when needed. Having 2 separate packages
actually helped make things much clearer in my mind.

On Mon, Nov 28, 2011 at 7:10 AM, Michael Snoyman <
reply@reply.github.com
> wrote:

> Has anyone actually *said* that the enumerator dependency is the
> reason they aren't interested in contributing? I think extra packages
> are a bad move.
>
> ---
> Reply to this email directly or view it on GitHub:
>
> https://github.com/yesodweb/persistent/commit/41f3a00cc554185b1a7ce0e95a32b40e1c297ba2#commitcomment-750398
>