Add output of system_dependencies install to build process

[Jacob-Stevens-Haas]

Details

The RTD documentation lists the steps of the build process that roughly correspond to the steps on a build's status page (e.g.). However, the system_dependencies step doesn't have an entry in the build logs.

• Build URL: https://readthedocs.org/projects/pysindy/builds/20026092/

Expected Result

Our build uses a sphinx extension that requires pandoc, itself a non-python dependency. Since we didn't include build.apt_packages in our config (didn't know about it), I would've expected the build to fail, as it does on a developer machine that does not have the pandoc apt package or windows install.

Actual Result

It built successfully. Obviously, wondering why things are working is better than wondering why they're broken, but even better would be to see the output of the system_dependencies step on our build status page. Apparently pandoc was added to rtd way back in 2014. But as another developer noted (and was confused about) in #4987, there's nothing in the RTD documentation (i could find) about pandoc being available, just that ancient lore.

Comments

In general, seeing dependency versions in build output feels like a good thing, unless there's a security issue to sharing that. It would have at least solved my and the other person's issue. Any thoughts?

[stsewd]

Hi, this dependency is installed by default in the docker image https://github.com/readthedocs/readthedocs-docker-images/blob/03b076eafeceaa84de34701d9b0b87fc5ae39936/Dockerfile#L48, that's why it doesn't appear as an step in the build process.

But +1 on linking to our dockerfile maybe.

[humitos]

@Jacob-Stevens-Haas

would be to see the output of the system_dependencies step on our build status page

This is shown in the build details page. These dependencies are the ones installed by the user when defining build.apt_packages.

The ones that are not shown are those installed by default in the Docker image used to build the documentation.

@stsewd

But +1 on linking to our dockerfile maybe.

Users shouldn't be aware of our Dockerfile at all. This is internal and should not be used/exposed, IMO. If anything, we could expose "all the packages and versions installed on each of this images" as a reference in our documentation.

[Jacob-Stevens-Haas]

As a user, I'd have a minor preference for seeing package installs in the build status page if possible, because (a) that's where any troubleshooting starts and (b) versions will always stay up to date. But any add'l documentation would be welcome.

Users shouldn't be aware of our Dockerfile at all.

I don't have much investment in the decision and far from a security expert, but are you suggesting to take that repo private?

[humitos]

@Jacob-Stevens-Haas

As a user, I'd have a minor preference for seeing package installs in the build status page if possible, because (a) that's where any troubleshooting starts and (b) versions will always stay up to date

The packages are already installed in the Docker image, so they are not installed on each build.

I don't have much investment in the decision and far from a security expert, but are you suggesting to take that repo private?

Nope. I'm saying we should not point people to that repository nor tell them to explore how our Dockerfile works.

[humitos]

Users wanting to know exactly what are the packages installed on Read the Docs images at build time can execute the following command: dpkg -l | grep -E "^ii". This can be done via build.jobs.