DOCPR-1799 fix for adding support limitation#16
Conversation
…ns or customizations
1635ea2 to
012ee3e
Compare
373a90d to
047dd74
Compare
|
The spell check failure is caused by a bug that came about when we incorporated sphinx-llm. I'm bringing in the patch fix from the sphinx-stack repo with #17. |
|
@jahn-junior would you know by when you'll be able to bring in the patch fix here for the spell check failure resolution? |
|
If you rebase this now @shaloo it should pass. |
a-velasco
left a comment
There was a problem hiding this comment.
Thanks for the bonus whitespace cleanup :)
|
|
||
| If any additional extensions need specific Python packages, ensure they are installed alongside the other requirements by adding them to the ``docs/requirements.txt`` file. | ||
|
|
||
| The Sphinx Stack fully supports only the third-party extensions included in the Starter pack. Support is limited for extensions you add or customize in requirements.txt |
There was a problem hiding this comment.
I suggest phrasing it a bit more explicitly to avoid confusion between Sphinx Stack/Starter pack.
| The Sphinx Stack fully supports only the third-party extensions included in the Starter pack. Support is limited for extensions you add or customize in requirements.txt | |
| The only third-party extensions the Sphinx Stack fully supports are those included via the [canonical-sphinx extension bundle](https://github.com/canonical/canonical-sphinx). |
There was a problem hiding this comment.
@jahn-junior thank you for this improvement. Is it okay if I add the expectation-setting boundary as shown below?
The only third-party extensions the Sphinx Stack fully supports are those included in the [canonical-sphinx extension bundle](https://github.com/canonical/canonical-sphinx). Support is limited for any additional or customized extensions added via requirements.txt.
There was a problem hiding this comment.
To clarify what I meant in my last review, I'd like as little emphasis on canonical-sphinx as possible. It clashes with how we treat canonical-sphinx these days—strictly as a theme—and will be outdated with the release of Ulwazi. The only reason we still set up extensions in canonical-sphinx is for backward-compatibility.
When it comes to the extensions we support, users should look to the default requirements.txt file.
I suggest something like:
The only extensions formally supported by the Sphinx Stack are those included in its default requirements.txt file. If you add any extensions to this list, it's your responsibility to ensure that they're compatible with the rest of the Sphinx Stack.
jahn-junior
left a comment
There was a problem hiding this comment.
The added text doesn't quite reflect our supported extensions. We do support all of the extensions listed in the Sphinx Stack requirements.txt file. Because canonical-sphinx is included in this file, we do also support the extensions it sets up.
However, we do not recommend using the optional full dependency group, and this change could be interpreted as though we do. So, I think for simplicity's sake, we should just say that we only fully support the extensions listed in the default requirements.txt file. Since canonical-sphinx is getting deprecated soon, this is also more future-proof.
Co-authored-by: Andreia <andreia.velasco@canonical.com>
| If your project requires additional extensions beyond the default list, add the | ||
| extension list to the new project in ``docs/requirements.txt``. | ||
|
|
||
| The legacy Sphinx Stack fully supports only the third-party extensions included in the Starter pack. Support is limited for extensions you add or customize in requirements.txt |
There was a problem hiding this comment.
| If your project requires additional extensions beyond the default list, add the | |
| extension list to the new project in ``docs/requirements.txt``. | |
| The legacy Sphinx Stack fully supports only the third-party extensions included in the Starter pack. Support is limited for extensions you add or customize in requirements.txt | |
| The Sphinx Stack supports a reasonable set of default extensions. If your project requires additional extensions, add them to the project's ``docs/requirements.txt`` file. | |
| It's your responsibility to ensure that extensions you add to this list are compatible with | |
| the rest of the Sphinx Stack. |
Mirroring my other suggestion. Also updated the preceding sentence to make this flow a little better.
|
|
||
| If any additional extensions need specific Python packages, ensure they are installed alongside the other requirements by adding them to the ``docs/requirements.txt`` file. | ||
|
|
||
| The Sphinx Stack fully supports only the third-party extensions included in the Starter pack. Support is limited for extensions you add or customize in requirements.txt |
There was a problem hiding this comment.
To clarify what I meant in my last review, I'd like as little emphasis on canonical-sphinx as possible. It clashes with how we treat canonical-sphinx these days—strictly as a theme—and will be outdated with the release of Ulwazi. The only reason we still set up extensions in canonical-sphinx is for backward-compatibility.
When it comes to the extensions we support, users should look to the default requirements.txt file.
I suggest something like:
The only extensions formally supported by the Sphinx Stack are those included in its default requirements.txt file. If you add any extensions to this list, it's your responsibility to ensure that they're compatible with the rest of the Sphinx Stack.
CHANGELOG.mdwith relevant non-documentation file changes?