d44a473e27
* lang/python/doc/src/gpgme-python-howto.org: Fix chmod race. * lang/python/examples/howto/export-secret-key.py: Likewise. * lang/python/examples/howto/export-secret-keys.py: Likewise. * lang/python/examples/howto/temp-homedir-config.py: Likewise. -- It's not for Python 2.7. GnuPG-bug-id: 6466 Reported-by: Hanno Böck Co-authored-by: Ingo Klöcker Signed-off-by: NIIBE Yutaka <gniibe@fsij.org> |
||
---|---|---|
.. | ||
meta | ||
rst | ||
src | ||
texinfo | ||
Makefile.am | ||
README |
GPGME Python Bindings Documentation =================================== As the GPGME Python bindings exist in two worlds within the FOSS universe, it's always had a little issue with regards to its documentation and specifically to the format of it. The GnuPG Project, like much of the rest of the GNU Project, uses Texinfo to build its documentation. While the actual format used to write and edit that documentation is Org mode. Largely because most, if not all, of the GnuPG developers use GNU Emacs for much of their work. The Python world, however, utilises reStructuredText almost universally. This in turn is used by Sphinx or Docutils directly to build the documentation. Each has various advantages for their own ecisystems, but this part of the GnuPG effort is aimed at both sides. So, long story short, this documentation is provided as both Texinfo and reStructuredText files. This docs directory contains four main subdirectories: 1. meta 2. src 3. rst 4. texinfo The Meta directory is for docs that are not intended for distribution or are about the docs themselves. The sole exception being this README file. The Src directory is where the original edited files are, from which the following two formats are generated initially. Most, if not all, of these are written in Org Mode. The ReST directory contains reStructuredText files which have been converted to that format from the Org Mode files via Pandoc. The Texinfo directory contains Texinfo files which have been exported to that format from the Org Mode files by Org Mode itself within GNU Emacs. Those latter two directories should then be used by their respective build systems to produce the various output file formats they normally do. They should not spill out into this parent directory. Particularly since it is quite possible, perhaps even likely, that alternatives to both of them may be added to this parent documentation directory at some future point.