instead of applying this only to usage generation, use it as a generic
mechanism to disable loading of Cython code.
it may be incomplete: there may be other places where Cython code is
loaded that is not checked, but that is sufficient to build the usage
docs. the environment variable used is documented as such in the
docs/usage.rst.
we also move the check to a helper function and document it
better. this has the unfortunate side effect of moving includes
around, but I can't think of a better way.
the current instructions create a dirty tree that `git add .` would
commit into git. this is error prone and somewhat unclean.
i found it preferable to change the `.gitignore` than to change the instructions, since there are probably `borg-env` environments lying around everywhere already.
this is such a crude hack it is totally embarrassing....
the proper solution would probably be to move the `build_parser()`
function out of `Archiver` completely, but this is such an undertaking
that i doubt it is worth doing since we're looking at switching to
click anyways.
the main problem in moving build_parser() out is that it references
`self` all the time, so it *needs* an archiver context that it can
reuse. we could make the function static and pass self in there by
hand, but it seems like almost a worse hack... and besides, we would
need to load the archiver in order to do that, which would break usage
all over again...
this is an unfortunate rewrite of the manpage creation code mentionned
in #208. ideally, this would be rewritten into a class that can
generate both man pages and .rst files.
first off, this required ticking the `Install your project inside a
virtualenv using setup.py install` box in the advanced config.
then, i had to disable all the C extensions build and disable some
checks, based on whether we are running on RTD or not.
still missing: usage builds and possibly other stuff that is in our
Makefile and not in setup.py.
instead of a boring table of contents, try to show our more exciting README file
it's still a wall of text, but at least all the buzzwords and highlights are there
ideally, the table of contents would be in the sidebar, but i don't know how to do that
link to the locations of different tools when I know them. i marked
the ones I don't know about specially so we can document those as
well.
point to the Github releases for the standalone binaries upload
we stop supporting them, because there are better alternatives:
- use a distribution package (from your linux distribution), if available
- use a pyinstaller binary provided by us (they include all you need in 1 file and
thus have better compatibility properties and are easier to install than a wheel)
- install from source (pypi or git) if everything else fails
