On Feb 11, 2011, at 11:20 AM, Peter Simons wrote:
If hledger offers optional features by means of Cabal flags, then
users
of the library need the ability to depend on hledger with a specific
set
of features (flags) enabled or disabled, but unfortunately Cabal can't
do that.
The new approach remedies that problem by placing optional features in
separate packages. That creates a different problem, however, because
users may now install hledger and hledger-web separately, which --
as we
know -- may create all kinds of version conflicts that are non-trivial
to resolve.
This is the problem you're now trying to solve by over-specifying the
dependencies of hledger. Arguably, though, Cabal should solve that
problem for the user, i.e. by offering to re-compile hledger to
resolve
the conflict etc., but unfortunately Cabal can't do that either.
Hi Peter.. thanks for the follow-up. In case it wasn't clear, I do
realise now that attempts to over-specify depedencies to avoid
practical cabal install issues can backfire, and a package author
should just accept that cabal install can't be made 100% reliable
installation method for non-experts (for now - I know many people are
thinking about this).
And, I've fixed/relaxed the process dependency in hledger head, and
only laziness/business has prevented that from being released to
hackage. I'll do that asap.
Cheers - Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
