-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The procedure described in CONTRIBUTING.rst is broken #48
Comments
Seems that sphinx and the theme are not installed. This worked for me:
|
Hi! Thanks for the report. Yeah, the image doesn't contain all the python packages needed to build the documentation since rtd.org creates a venv and install some packages by default on this env. So, to imitate the behaviour from rtd.org it's needed to do:
Would you like to propose a PR for the docs? |
I wouldn't mind to open a PR in order to enhance the docs. However, I am not sure about the content I should add. The solution I provided works for html output generation. So does yours (I expect). Therefore, what's the point in enhancing the test instructions if only one of the many options supported by RTD is tested there? I mean, I am missing a command which replaces 'make html' with |
This image/repostiroy is not to build RTD documentation itself outside the RTD codebase. So, the idea of "Test locally" is useful when you want to modify the image (for example when a latex font is missing and you want to add it to the docker image). So, you build your custom image and test that your documentation build without problems. If it builds, you can propose a PR with the addition of that font. That's the idea of the "Test locally". So, in case that the instructions for that are confusing, you can create a PR explaining those steps in a better way. |
The point here is that AFAIK executing
The following snippet works for me:
But Do you know whether it is possile to execute BTW, I tried the solution above, but I get:
|
Yeah. I mentioned just an example of the flow to test it.
This repo seems to be completely unmaintained (last commit 2014), so I'd say that it was just a test or an idea that was never really used.
I don't know. Just to mention, RTD doesn't use
No. It's complicated to test all the dependencies together since there is no project template that uses all of them; but I think it'd be awesome to have something like that to ensure that any new change to the docker-images doesn't break anything. |
Well, do you know a few projects which use non-frequent or even rare features?
If you inspect the Makefile, you'll find that every call is to sphinx-build. However, the builders which are actually used in RTD.org (e.g. https://readthedocs.org/projects/ghdl-devfork/builds/6440145/) are custom (named |
We could perhaps also deviate from prescribing Otherwise, testing a full pdf and epub build should probably be the point of the test build. I'd vote for the minimal number of steps/requirements to test a project build -- so no virtualenv and we don't suggest all of the RTD dependencies. Edit: Opened #53 to discuss integration tests |
It says:
When I try to follow this procedure I get this:
The same happens when I try
docker run --rm -t -i readthedocs/build:2.0 /bin/bash
The text was updated successfully, but these errors were encountered: