search

alpmestan / servant

Moved to http://github.com/haskell-servant
50 stars 1 forks source link

Modular split #39

Closed alpmestan closed 9 years ago

alpmestan commented 9 years ago

This PR splits our initial servant package into:

This enables us (and any future servant user) to only depend on the bits we need for a particular project. For example, you won't drag lens or http-client if you're just defining a server.

@jkarni @soenkehahn I'd appreciate it if you can give this a whirl before I merge, to make sure I haven't screwed up anything. This builds just fine and the tests pass.

soenkehahn commented 9 years ago

I am a bit conflicted about this. I get that we want to avoid unnecessary dependencies (and linking a server application with http-client without using it at all seems bad). But managing more packages adds overhead. @alpmestan: Are you sure this is the best way to go?

(Btw, what depends on lens?)

Sorry, I haven't tested the commits. I'm fine with things breaking for now, though.

jkarni commented 9 years ago

But client and jquery surely should both be separate? I'm in favor of the split as it currently stands, but the place where I can go either way is servant-docs not being separated out.

I think splitting it into different packages underlines the modular, plugin nature of servant, which is of course nice. I guess one compromise would be to then have a meta-package...

alpmestan commented 9 years ago

@soenkehahn

I am a bit conflicted about this. I get that we want to avoid unnecessary dependencies (and linking a server application with http-client without using it at all seems bad). But managing more packages adds overhead. @alpmestan: Are you sure this is the best way to go?

What bothers you with splitting things up into several package? The fact that you can't just depend on one package because you tend to use them all? In that case, we can provide a metapackage as @jkarni says.

(Btw, what depends on lens?)

servant-docs and servant-jquery, it's much handier to build up the ADTs with lenses although we could do without them.

alpmestan commented 9 years ago

@jkarni

But client and jquery surely should both be separate? I'm in favor of the split as it currently stands, but the place where I can go either way is servant-docs not being separated out.

Why? My first motivation for that was not to force a lens dependency down people's throat. So you'd leave the docs bits in the core servant package?

I think splitting it into different packages underlines the modular, plugin nature of servant, which is of course nice. I guess one compromise would be to then have a meta-package...

I'd be happy with that solution. But as usual, I'd rather have us "vote". I went ahead and implemented the split to get a feel of how it'd be like so that we could make an informed decision.

soenkehahn commented 9 years ago

It's more a general reservation against having too many packages. (So, creating a new meta-package is not something I would favor. ;)

Having multiple packages complicates things. Hackage uploads become more work. For changes to the core, we also would need to execute the test-suites of all packages, to make sure everything still fits together. Also there is no central place for haddock docs anymore. And we would have to add central documentation about which packages exist and how they play together. (Which @alpmestan did nicely in the README. But we would need that for hackage, too, I think.)

To clarify: I'm not really against this change and I see the advantages. But I also see some downsides.

I think I would have left servant-client in the core. I don't worry too much about the added http-client dependency. (Which is exactly the opposite of what @jkarni suggested. Well, it seems to be a bit a matter of taste.)

jkarni commented 9 years ago

@soenkehahn those are good points, and they're pretty close to swaying me.

On another note, I'd rather not split packages based on what dependencies we could, in the current state of things, help people avoid. Partly that's because I'd prefer a more conceptually clean (rather than practical) split, but more it's because we'd probably be stuck with this decision way after the landscape of dependencies has changed.