base-compat-batteries provides the same API across more ghc versions
than base-compat does, at the cost of more dependencies. Eg it exports
Prelude.Compat ((<>)) with ghc 7.10/base 4.8, which we expect.
My belief is that several of our deps already require it so the added
cost is not too great. We should probably go back to base-compat when
possible though, eg when we stop supporting ghc 7.10.
We don't need to import Data.Monoid because Prelude.Compat exports "<>"
already. In fact, importing that module causes build failures:
Hledger/Read/Common.hs:725:62: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Sem.<>’,
imported from ‘Prelude.Compat’ at Hledger/Read/Common.hs:97:1-39
(and originally defined in ‘Data.Semigroup’)
or ‘Data.Monoid.<>’,
imported from ‘Data.Monoid’ at Hledger/Read/Common.hs:110:1-18
Fixes https://github.com/simonmichael/hledger/issues/794.
It's rare that my deps break their api or that newer versions must be avoided,
and very common that they release new versions which I must tediously
and promptly test and release hackage revisions for or risk falling out
of stackage. Trying it this way for a bit.
The .hledger-web_client_session_key.aes file written at startup is
cluttersome and means hledger-web can only be started from a writable
directory. What do we lose if I disable it ?
https://hackage.haskell.org/package/yesod-core-1.4.33/docs/Yesod-Core.html#v:makeSessionBackend
says "Default: Uses clientsession with a 2 hour timeout."
http://hackage.haskell.org/package/clientsession-0.9.1.2 says
"Securely store session data in a client-side cookie."
I think: hledger-web saves (eg) the state of the sidebar as session
data, in a cookie, and my web browser saves that locally. And this
still seems to work, across server restarts. So what's the purpose of
saving this "client session" file on the server ? Let's disable it and
find out.
