We Keep Coding

How do I configure a sphinx extension?

In the documentation about sphinx extensions are some "config values". e.g. in sphinx.ext.autodoc.
But I do not know how to set these values. Is it a parameter on the shell I have to set?

There's a page on the docs that teaches how to use extensions. The page is here: https://www.sphinx-doc.org/en/master/usage/extensions/index.html
In this page you have the following description:
A list of strings that are module names of extensions. These can be extensions coming with Sphinx (named sphinx.ext.*) or custom ones.
This tells you that sphinx.ext.* are the built-ins extensions (You can confirm that from here)
Basically when it states some kind of configuration, it refers to the conf.py file that is generated when you run sphinx-quickstart, which is a quick-setup command for sphinx in general (Might be a good read: https://www.sphinx-doc.org/en/master/usage/quickstart.html)
The root directory of a Sphinx collection of plain-text document sources is called the source directory. This directory also contains the Sphinx configuration file conf.py, where you can configure all aspects of how Sphinx reads your sources and builds your documentation.
Sphinx comes with a script called sphinx-quickstart that sets up a source directory and creates a default conf.py with the most useful configuration values from a few questions it asks you.
Note that, as it's built-in, it's already setupped with your sphinx project.
But if you want to customize it somehow, you can use conf.py file with autodoc_* configurations (As listed here)
There are also some notes that might be useful for your case
For Sphinx (actually, the Python interpreter that executes Sphinx) to find your module, it must be importable. That means that the module or the package must be in one of the directories on sys.path – adapt your sys.path in the configuration file accordingly.

Using Sphinx to document multiple Python projects

I've read a few Sphinx tutorials but I'm still a bit hung up on how I set up multiple projects.
What I mean is, after installing Sphinx, this guide says
To get started, cd into the documentation directory and type: $ sphinx-quickstart
Let's say I have 5 separate Python projects each in it's own directory (all individual git repos, etc).
My question is, what exactly is "the documentation directory" (aside from the obvious) and how do I set up Sphinx when working with multiple projects?
Do I make one "master documentation directory" somewhere and as I use Sphinx, do I create sub directories for each project or similar?
Or do I create a "documentation directory" inside of each of my projects and run $ sphinx-quickstart to set up Sphinx for each individual project?
I'm trying to understand the big picture here but can't find a tutorial that spells out this aspect of things.

The sphinx-quickstart command generates a documentation skeleton for a single project, so if you have multiple separate projects you will have to run it in each one of them. The link you posted uses the phrase "documentation directory" because the directory name and relative position in the project directory is up to you (they appear to be putting it in project_root/doc), not because there should be some centralised directory of documentation for all of your projects.

Multi-target solution builder

An opensource project currently uses CMake to generate project files for multiple versions of Visual Studio.
I noticed that Node uses python script to do a similar thing but is more elegant since the output of the tool doesn't hardcode directory paths into those project files. However the current node setup only seems to support 2010 and 2012. The node documentation doesn't say what the build tools are just "The build tools distributed with Node run on python."
The batch file included with Node calls python configure, but doing a search on that returns a zillion unrelated results.
I was wondering if this tool/script is
an open source project with website, documentation, etc.
extensible to earlier versions of VS (2003 onwards).
What I am looking to do is produce a bunch of solutions and projects that should just work straight out the box and not be tied to a particular dev's directory layout like CMake does. Also the script allows me to easily update multiple scripts if a file gets added or removed.

It turns out Node uses GYP to generate it's project files. I had a quick play earlier and seems fairly easy to use.

Python command line program: generate man page from existing documentation and include in the distribution

Following an (hopefully) common practice, I have a Python package that includes several modules and an executable script in a separate scripts directory, as can be seen here.
The documentation for the script, apart from the auto-generated help given by optparse, is together with the package documentation in a Sphinx subdirectory. I am trying to:
generate the man page for the script from the existing documentation
include the man page in the distribution
I can easily do #1 with Sphinx, the man_pages setting and sphinx-build -b man. So I can call python setup.py build_sphinx -b man and have the man page generated in the build/sphinx/man directory.
Now I would like to be able to have the generated man page included in the distribution tarball, so GNU/Linux packagers can find it and install it to the proper location. Various options like package_data do not seem to work here because the man page is not there until it is generated by Sphinx. This could also apply to i18n files (.mo vs .po files).
Including files that are not part of the source in MANIFEST.in doesn't seem right. The possibility of commiting the generated files to the source repository looks like an awful thing to do and I would like to avoid it.
There should be one-- and preferably only one --obvious way to do it.

To add static man pages in you distribution, you can add them in the MANIFEST file.
recursive-include docs *.txt
recursive-include po *.po
recursive-include sample_data *
recursive-include data *.desktop *.svg *.png
include COPYING.txt
include README.txt
recursive-include man_pages
Where man_pages is the directory containing the copies of generated man pages.
See also: http://linuxmanpages.com/man1/man.1.php

I would cause setup.py to generate the man pages probably before calling distutils.core.setup. Remember that setup.py at one level is python code. You want to test and make sure that it works even if sphinx is not installed (unless you require sphinx). So, if the man pages already exist and sphinx is not available do not fail. That way someone who unpacks your source distribution without sphinx can still run setup.py build and other targets.
The other option is to check in the man pages, but like you, I find that ugly.

The thing that I have seen done before is to provide a build target for your docs and make it clear in the README file that the documentation includes man pages and can be built by running that build target. Package maintainers then build your docs and package them during the package creation process.
The fedora 18 rpm for hawkey, for example, builds this way. I have also seen other rpms follow the model of building documentation at the same time as the source is built, then packaging it.

This question deserve a better answer, and not only because this issue has been bothering me for a while. So here is my implementation.
Download build_manpage.py from my github project (here is a link to build_manpage)
Save it somewhere you can import it to your setup.py
# inside setup.py
from setuptools import setup
from build_manpage import BuildManPage
...
...
setup(
...
...
cmdclass={
'build_manpage': BuildManPage,
)
Now you can invoke setup.py like this:
$ python setup.py build_manpage --output=prog.1 --parser=yourmodule:argparser

Python 3.2: How to setup versioning for a project

Ok, so I have been looking around and I have seen a couple different options although i am new to python so i am a bit confused. Here is what I am looking for:
I have a project of multiple .py files. I have my files and a lib directory for the libraries i have created. My question is, how do i setup the project to have a version? I see a lot of articles saying that I put the version in setup.py. Where does setup.py go? what else needs to be in that setup.py file? Do I just import setup.py into my python files? How can i check to see if it worked? How can i check the version of each .py file to make sure it imported correctly?

Read hitchhiker's guide to packaging to learn good practice for developing a Python project
The setup.py file is at the heart of a Python project. It describes all of the metadata about your project. There a quite a few fields you can add to a project to give it a rich set of metadata describing the project. However, there are only three required fields: name, version, and packages. The name field must be unique if you wish to publish your package on the Python Package Index (PyPI). The version field keeps track of different releases of the project. The packages field describes where you’ve put the Python source code within your project.
Our initial setup.py will also include information about the license and will re-use the README.txt file for the long_description field. This will look like:
from distutils.core import setup
setup(
name='TowelStuff',
version='0.1dev',
packages=['towelstuff',],
license='Creative Commons Attribution-Noncommercial-Share Alike license',
long_description=open('README.txt').read(),
)

Typically a project will include it's version as an __version__ attribute within its top level namespace.
For example:
>>> import myproject
>>> print myproject.__version__
'3.2.0'
See http://www.python.org/dev/peps/pep-0396/ for more info and ways to access __version__ from within your setup.py file.