I didn't think this was installed by the build system. Is this an update to the documentation?

This would be an improvement. As far as I can tell, this project doesn't need or benefit from autotools; it's easier to develop and build Python packages by sticking closely to the modern Python ecosystem.

I've been looking over the build system and making a checklist of changes and thoughts:

• If autotools is removed, the boostrap.sh file can be removed. Besides autotools setup, all bootstrap.sh does is call git submodule update --init. That can be done manually.
• The build tool doesn't need to create a virtual environment for a developer. They can create a virtual environment at their own discretion. I think this is how most projects do things?
• Several of the Python packages are installed using pip. For example, the command ./bin/pip install sphinxcontrib-applehelp sphinxcontrib-htmlhelp sphinxcontrib-jsmath appears in Dockerfile-debian-11-sqlite. These requirements can be stuffed in a requirements.txt file. Then python -m pip install -r requirements.txt will handle the installation.
• I don't think source should be pulling bower down. bower can be added as a dependency when packaging. Otherwise, the developer should be able to figure it out.
• IMO, bower should be called manually.
• pdf.js can be put into bower.json. That's one less submodule.

To hack on mediagoblin with this system, the developer would need to do something like the following:

python3 -m venv venv
source venv/bin/activate
git submodule update --init
npm install
python setup.py install

This seems okay. I doubt it's convenient or useful to package mediagoblin on pip, but if the build structure is modernized it should be easier to hack on and package the project as a .deb.

Final thought: Does it even make sense to have a setup.py? I don't expect other code to call into mediagoblin, unless celery the celery tasks need a way to import it.