A single transaction can be added by PUT to /add.
(I read that PUT, not POST, should be used to create;
perhaps the web add form should also use PUT ?)
As with the web form, the `add` capability is required (and enabled by
default).
Here's how to test with curl:
$ curl -s http://127.0.0.1:5000/add -X PUT -H 'Content-Type: application/json' --data-binary @in.json; echo
New readJsonFile/writeJsonFile helpers in Hledger.Web.Json
are handy for generating test data. Eg:
>>> writeJsonFile "in.json" (head $ jtxns samplejournal)
These have been an adhoc mixture of plain text, markdown and org, and
used in each mode at different times. They will now have a definite
format, which for now is markdown. Org was another contender.
[ci skip]
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.
I dropped these last month, perhaps without meaning to.
They probably should stay. hledger-ui (eg) will still build
with minor updates of hledger-lib or hledger, but will require
either a release or a hackage revision to build with a major
update.
Older megaparsec is still supported.
Also cleans up our custom parser types,
and some text (un)packing is done in different places
(possible performance impact).
hledger-lib had a valid install plan with GHC 7.8, but requires GHC 7.10 to compile (currently).
Require base 4.8+ everywhere so that stack/cabal will enforce a supported GHC version early.
Also, bump hledger-ui's "stability" to "stable".
Generated package.yaml files from the old cabal files with hpack-convert,
removed some problematic blank lines manually,
regenerated the cabal files from the package.yaml files with hpack.
Tests pass, looks like all the info is still there.
This means that from now on, we don't edit cabal files directly.
We edit the less verbose package.yaml files. stack will update
the cabal files automatically (or non-stack users can use hpack).
The changes to both are committed, as we still want to provide
the cabal files to downloaders.
Make these modules' names more like the heavily-used types they
define (CliOpts, UIOpts, WebOpts). This is consistent with
RawOptions and ReportOptions, and helps with code navigation.
Here are hpack package.yaml files for the other hledger cabal files.
These remove a lot of human-error-prone duplication.
They are not used yet as hpack isn't quite mature enough -
when it supports flags and benchmarks we will probably switch.
