Thanks to the latest cargo 0.3.0, it's possible to keep everything
in the stanard doc output directory, which essentially collects
everything for us.
This creatly reduces the space required to hold all documentation, and
is in fact quite beatiful.
All assets are configured via shared.yaml and are located elsewhere in
the web. This could lead to broken assets at some point, but I am just
risking it for know, knowing that it's easily done to have local
resources.
Closes#106
[skip ci]
Previously, even though the request was passed by reference, it was
copied and thus our changes never arrived in the call.
Now the API makes this clear by taking ownership, and the CLI code
sets the Request value lateron, explicitly.
Related to #76
* implement custom scopes - previously they could be set, but were
ignored during the API call
* api-overrides are not yaml files for convenience. Existing ones were
updated as needed.
Fixes#75
* updated all json API descriptions
* enabled 'pretty' printing of response structures. However, currently
there is no way to get rid of all the NULL fields without external
filtering
* all structure fields are now optional - there seems to be no way
around it.
Fixes#73
It's implemented in a working fashion, except that the default value
is not currently set to something sensible, causing duplicate errors in
case the key-value syntax is wrong.
Related to #61
* Instead of writing pod-types, we generate a random value of the
required type.
* Fully document how cursors can be set, which is all that's usually
demonstrated in more complex dynamic structure documentation
Fixes#49
* in APIs, scopes will now be per-method, and if no scope is given,
we will assume only the API key has to be set. Previously there was
a wild mix between globally mentioned scopes and method scopes.
* assure CLI generation works so far, for all avaialable APIs
Related to #48
Previously we put cli.py into the common lib folder, which caused the
API to be regenerated and rebuilt whenever we changed code that will
only affect the CLI, causing terrible turnaround times.
Now the dependency is fixed.
That way, all information can be placed within a single markdown file
per method call. This will keep loading times low while maximizing
usability.
That way, it's comparable to the API documentation, which is most
detailed on a per-method basis as well.
That way, a single huge markdown file containing documentation for
commands and methods can be split up into multiple files for
individual inclusion in mkdocs.
It's done by a post-processor which is loaded by mako-render, providing
access to the entire context. Said processor may also drop results
altogether and thus prevent files to be written that have been split up
by it.
* allow to rename executables, for now just brute-force using a boolean
flag. If we have more binaries at some point, we might want to be more
elaborate.
* everything related to docopts functionality is now in the docopts
module.
Related to #45
It can be selected for each type of program we want to build, and makes
sense for everything that is not a library.
We also tried to unify names and folders a bit more, even though there
certainly is more work to be done to be fully non-redundant.
Fixes#43
This is the first of many changes to come.
We try to leverage our ability to merge multiple data source into one
to abstract away what we are actually doing, and of course, to allow
sharing the majority of the code, were applicable.
When documenting mandatory arguments of a methods builder, it was
possible to document 'parts', which have a long multi-line description
with empty lines inbetween. This caused the indentation to be funny
and tricked rustdoc into thinking these are indented doc-tests.
Now we remove these empty lines, also hoping we dont encounter lines
with just whitespace in them. The latter would require a tiny update
of our regex.
We will now keep marker files to remember which crates we have published
successfully. These files are checked in to make this information
persist.
NOTE: We still don't explicitly exclude pseudo-changes in json files,
which are no real change except for a changed revision number.
Fixes#41
