That way, changes can be tracked.
Also, we make it official.
Future checkins will only be made if major changes were done,
similar to how the APIs are handled.
Related to #64
This works already for simple request values, but doens't generate
compiling code for structures with Parts in them.
Nonetheless, it's a big step towards finishing the overall issue.
Related to #64
The trick was to use an actual list of cursor tokens that is consumed
on use. That way, we don't loose track of were we are in the
structure.
Related to #64
We handle errors gracefully with costum types and minimal amount of
code. Unfortunately, Mime type parsing is very 'flexible', allowing
nonesense types to be passed easily.
Related to #62
* API-docs now adjust depending on where 'alt' is set (either as global
parameter, or as method-parameter)
* CLI: download tracking now works for 'alt' as method-parameter
* CLI: global parameter remapping allows them to be named consistently,
but map to the name required by the google API.
Fixes#61
* set globally shared parameters (which includes 'alt')
* track if 'alt' is set to 'media' at runtime to do the right thing when
outputting the result. There is still an issue to be fixed though
Related to #61
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
We are parsing required scalar values and handle parse-errors correctly,
to the point were we make a simple, non-upload doit() call.
It shows that we seem to build invalid calls, for now,but that's nothing
we can't fix once the time is ripe.
Next goals will be related to finalizing the argument parsing code.
Fixes#60
Now we are able to cleanly handle our arguments on a per-method basis.
The generated code won't clutter our design as we put the details into
their own methods.
Fixes#59
The hub is just using preset types - we will have to implement our own
storage and auth-delegate, as well as a Hub delegate at some point.
Dry run mode allows us to check for errors and use a call builder
using the very same code.
Fixes#57
* if there is no secret file in json format, we write a default one
that we will then read in a second iteration of the loop.
That way, the user has an example of how such a file must look like.
Next step is to cleanup the error type and implement the Error trait.
Fixes#53
* 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
We build all required -r flags using absolute cursor positions only.
The next step should be to use relative ones, and of course be more
verbose about how this should be interpreted (sequential).
* 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
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.
