For now we just have a 'dum' example, but once we are there, we shall
make the example and documentation based on the actual request value.
This requires some additional work, which fortunately has to be done
in python only.
Grammar is laid out per method, providing general purpose arguments
only as needed/supported.
All details will be contained in the markdown documentation.
Related to #45
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.
Otherwise, it would overwrite its search index, effectively breaking
the search field.
We might run into space issues on github, as the generated docs are
duplicating each other and use a lot of disk-space.
Fixes#48
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
* macro 'alias' was renamed to 'rename'
* fixed `cargo test` on main project
The latter pointed me to the serde issue, which would have made
everything fail when actually used to communicate with google servers.
* keywords are no longer than 20 characters, which is a restriction
cargo imposes
* don't use 'homepage' link in cargo.toml unless the homepage is
non-empty
* Added all publish-results to mark the respective crate version
Related to #46
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 allows us to build efficiently. CLI programs can now have their
own cmn.rs implementation, which we can test standalone with
`cargo test`.
The primary makefile currently just explicitly pulls in the type-*.yaml,
one day we could possibly put it into a loop.
Fixes#11
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
* `ResourceMethodsBuilder` -> `MethodsBuilder`. This is now precise
enough. Previously it was just to similar to what's now a
`CallBuilder`
* Fixed whitespace issue in `doit()`
Previously, it would query the size from the wrong dict and obtain
the value 0 all the time. This would have made every upload fail with
`UploadSizeLimitExeeded`.
Now we obtain the actual size limit, and will ignore it if unset/0
for some reason.
Patch += 1
